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起步 



本章 介绍开 始使用 Git 前 的相关 知识。 我们 会先了 解一些 版本控 制工具 的历史 背景， 然后 
试着让 Git 在 你的系 统上跑 起来， 直到 最后配 置好， 可以 正常开 始开发 工作。 读完 本章， 你 
就 会明白 为什么 Git 会如此 流行， 为什 么你应 该立即 开始使 用它。 

1.1 关于版 本控制 

什么 是版本 控制？ 我 为什么 要关心 它呢？ 版本控 制是一 种记录 一个或 若干文 件内容 变化， 
以便将 来查阅 特定版 本修订 情况的 系统。 在本 书所展 示的例 子中， 我们 仅对保 存着软 件源代 
码的 文本文 件作版 本控制 管理， 但实 际上， 你可以 对任何 类型的 文件进 行版本 控制。 

如果 你是位 图形或 网页设 计师， 可 能会需 要保存 某一幅 图片或 页面布 局文件 的所有 修订版 

本 （这 或许 是你非 常渴望 拥有的 功能） 。 采用 版本控 制系统 （vcs) 是个 明智的 选择。 有 

了它 你就可 以将某 个文件 回溯到 之前的 状态， 甚至 将整个 项目都 回退到 过去某 个时间 点的状 
态。 你 可以比 较文件 的变化 细节， 查出 最后是 谁修改 了哪个 地方， 从而 找出导 致怪异 问题出 
现的 原因， 又是谁 在何时 报告了 某个功 能缺陷 等等。 使用版 本控制 系统通 常还意 味着， 就算 
你乱来 一气把 整个项 目中的 文件改 的改删 的删， 你也 照样可 以轻松 恢复到 原先的 样子。 但额 
外 增加的 工作量 却微乎 其微。 

1.1.1 本地 版本控 制系统 

许多 人习惯 用复制 整个项 目目录 的方式 来保存 不同的 版本， 或 许还会 改名加 上备份 时间以 
示 区别。 这 么做唯 一的好 处就是 简单。 不过 坏处也 不少： 有时 候会混 淆所在 的工作 目录， ― 
旦弄 错文件 丢了数 据就没 法撤销 恢复。 

为了解 决这个 问题， 人 们很久 以前就 开发了 许多种 本地版 本控制 系统， 大多 都是采 用某种 
简单的 数据库 来记录 文件的 历次更 新差异 （ 见图 1-1 ) 。 

其 中最流 行的一 种叫做 res, 现今 许多计 算机系 统上都 还看得 到它的 踪影。 甚至在 流行的 
Mac OS X 系统上 安装了 开发者 工具包 之后， 也可 以使用 res 命令。 它的工 作原理 基本上 
就是 保存并 管理文 件补丁 （ patch ) 。 文件 补丁是 一种特 定格式 的文本 文件， 记录着 对应文 
件修 订前后 的内容 变化。 所以， 根据 每次修 订后的 补丁， res 可 以通过 不断打 补丁， 计算出 
各 个版本 的文件 内容。 

1.1.2 集 中化的 版本控 制系统 

接 下来人 们又遇 到一个 问题， 如何让 在不同 系统上 的开发 者协同 工作？ 于是， 集中 化的版 
本控 制系统 ( Centralized Version Control Systems, 简称 CVCS ) 应运 而生。 这类系 
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图 1.1: 本地 版本控 制系统 



统， 诸如 CVS, Subversion 以及 Perforce 等， 都有一 个单一 的 集中管 理的服 务器， 保存 
所 有文件 的修订 版本， 而 协同工 作的人 们都通 过客户 端连到 这台服 务器， 取出 最新的 文件或 
者提交 更新。 多年 以来， 这已成 为版本 控制系 统的标 准做法 （ 见图 1-2 ) 。 




这种做 法带来 了许多 好处， 特别 是相较 于老式 的本地 VCS 来说。 现在， 每 个人都 可以在 
一定程 度上看 到项目 中的其 他人正 在做些 什么。 而管理 员也可 以轻松 掌控每 个开发 者的权 
限， 并且管 理一个 CVCS 要远比 在各个 客户端 上维护 本地数 据库来 得轻松 容易。 

事分 两面， 有好 有坏。 这么 做最显 而易见 的缺点 是中央 服务器 的单点 故障。 如果宕 机一小 
时， 那么在 这一小 时内， 谁都无 法提交 更新， 也就无 法协同 工作。 要是 中央服 务器的 磁盘发 
生 故障， 碰 巧没做 备份， 或者备 份不够 及时， 就会 有丢失 数据的 风险。 最坏的 情况是 彻底丢 
失整个 项目的 所有历 史更改 记录， 而 被客户 端偶然 提取出 来的保 存在本 地的某 些快照 数据就 
成 了恢复 数据的 希望。 但这样 的活依 然是个 问题， 你不能 保证所 有的数 据都已 经有人 事先完 
整 提取出 来过。 本 地版本 控制系 统也存 在类似 问题， 只要 整个项 目的历 史记录 被保存 在单一 
位置， 就 有丢失 所有历 史更新 记录的 风险。 
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1.1.3 分布式 版本控 制系统 

于是 分布式 版本控 制系统 ( Distributed Version Control System, 简称 DVCS ) 面世 
了。 在 这类系 统中， 像 Git, Mercurial, Bazaar 以及 Dares 等， 客户 端并不 只提取 最新版 
本 的文件 快照， 而是把 代码仓 库完整 地镜像 下来。 这么 一来， 任 何一处 协同工 作用的 服务器 
发生 故障， 事 后都可 以用任 何一个 镜像出 来的本 地仓库 恢复。 因为 每一次 的提取 操作， 实际 
上都是 一次对 代码仓 库的完 整备份 （ 见图 1-3 ) 。 
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( version 1 ) 
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图 1.3: 分布式 版本控 制系统 

更进 一步， 许 多这类 系统都 可以指 定和若 干不同 的远端 代码仓 库进行 交互。 籍此， 你就可 
以在同 一个项 目中， 分 别和不 同工作 小组的 人相互 协作。 你可以 根据需 要设定 不同的 协作流 
程， 比如层 次模型 式的工 作流， 而 这在以 前的集 中式系 统中是 无法实 现的。 

1.2 Git 简史 

同生 活中的 许多伟 大事件 一样， Git 诞生 于一个 极富纷 争大举 创新的 年代。 Linux 内核开 
源项 目有着 为数众 广的参 与者。 绝大 多数的 Linux 内核 维护工 作都花 在了提 交补丁 和保存 
归档 的繁琐 事务上 （ 1991 - 2002 年间 ） 。 到 2002 年， 整个项 目组开 始启用 分布式 版本控 
制系统 BitKeeper 来管理 和维护 代码。 

到了 2005 年， 开发 BitKeeper 的商业 公司同 Linux 内核 开源社 区的合 作关系 结束， 他 
们收 回了免 费使用 BitKeeper 的 权力。 这 就迫使 Linux 开 源社区 （特 别是 Linux 的 缔造者 
Linus Torvalds ) 不得 不吸取 教训， 只有 开发一 套属于 自己的 版本控 制系统 才不至 于重蹈 
覆辙。 他们对 新的系 统制订 了若干 目标： 

□ 速度 

□ 简单 的设计 

□ 对 非线性 开发模 式的强 力支持 （ 允许上 千个并 行开发 的分支 ） 
□ 完全 分布式 



Computer B 

C m ) 
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□ 有能力 高效管 理类似 Linux 内核 一样的 超大规 模项目 （速 度和数 据量） 

自 诞生于 2005 年 以来， Git 日 臻成熟 完善， 在高度 易用的 同时， 仍 然保留 着初期 设定的 
目标。 它 的速度 飞快， 极 其适合 管理大 项目， 它还 有着令 人难以 置信的 非线性 分支管 理系统 
(见 第三章 ）， 可 以应付 各种复 杂的项 目开发 需求。 

1.3 Git 基础 

那么， 简单 地说， Git 究竟是 怎样的 一个系 统呢？ 请 注意， 接下 来的内 容非常 重要， 若是 
理解了 Git 的思 想和基 本工作 原理， 用起 来就会 知其所 以然， 游刃 有余。 在开 始学习 Git 的 
时候， 请 不要尝 试把各 种概念 和其他 版本控 制系统 （ 诸如 Subversion 和 Perforce 等 ） 相 
比拟， 否 则容易 混淆每 个操作 的实际 意义。 Git 在保 存和处 理各种 信息的 时候， 虽然 操作起 
来的 命令形 式非常 相近， 但 它与其 他版本 控制系 统的做 法颇为 不同。 理 解这些 差异将 有助于 
你准确 地使用 Git 提供 的各种 工具。 

1.3.1 直 接记录 快照， 而非差 异比较 

Git 和其 他版本 控制系 统的主 要差别 在于， Git 只关 心文件 数据的 整体是 否发生 变化， 而大 
多数 其他系 统则只 关心文 件内容 的具体 差异。 这 类系统 （CVS, Subversion, Perforce, 
Bazaar 等等） 每次 记录有 哪些文 件作了 更新， 以及都 更新了 哪些行 的什么 内容， 请看图 
1一4。 



■ Checkins over lime - 



( Version 1 J ( Version 2 j ( Version 3 ) ( Version 4 J ( Version 5 J 

( file A ) Al ) » ( A2 ) 

( file B ) Al ) A2 ) 

( file C ) ~~ Al ) A2 ) A3 ) 

图 1.4: 其 他系统 在每个 版本中 记录着 各个文 件的具 体差异 

Git 并 不保存 这些前 后变化 的差异 数据。 实 际上， Git 更像 是把变 化的文 件作快 照后， 记 
录 在一个 微型的 文件系 统中。 每次 提交更 新时， 它 会纵览 一遍所 有文件 的指纹 信息并 对文件 
作一 快照， 然 后保存 一个指 向这次 快照的 索引。 为提高 性能， 若文 件没有 变化， Git 不会再 
次 保存， 而只对 上次保 存的快 照作一 链接。 Git 的工 作方式 就像图 1-5 所示。 



- Checkins over time ■ 



( Version 1 J ( Version 2 j ( Version 3 ) ( Version 4 J ( Version 5 J 



dj do q cyj c 



图 1.5: Git 保存每 次更新 时的文 件快照 

这是 Git 同其 他系统 的重要 区别。 它 完全颠 覆了传 统版本 控制的 套路， 并对 各个环 节的实 
现 方式作 了新的 设计。 Git 更像是 个小型 的文件 系统， 但 它同时 还提供 了许多 以此为 基础的 
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超强 工具， 而不只 是一个 简单的 VCS。 稍后 在第三 章讨论 Git 分支 管理的 时候， 我 们会再 
看看 这样的 设计究 竟会带 来哪些 好处。 

1.3.2 近乎所 有操作 都是本 地执行 

在 Git 中 的绝大 多数操 作都只 需要访 问本地 文件和 资源， 不用 连网。 但 如果用 CVCS 的 
活， 差不多 所有操 作都需 要连接 网络。 因为 Git 在 本地磁 盘上就 保存着 所有当 前项目 的历史 
更新， 所以 处理起 来速度 飞快。 

举个 例子， 如果要 浏览项 目的历 史更新 摘要， Git 不 用跑到 外面的 服务器 上去取 数据回 
来， 而直接 从本地 数据库 读取后 展示给 你看。 所以任 何时候 你都可 以马上 翻阅， 无需 等待。 
如果想 要看当 前版本 的文件 和一个 月前的 版本之 间有何 差异， Git 会取 出一个 月前的 快照和 
当前文 件作一 次差异 运算， 而 不用请 求远程 服务器 来做这 件事， 或是把 老版本 的文件 拉到本 
地来作 比较。 

用 CVCS 的活， 没有 网络或 者断开 VPN 你 就无法 做任何 事情。 但用 Git 的话， 就算你 
在飞机 或者火 车上， 都可以 非常愉 快地频 繁提交 更新， 等 到了有 网络的 时候再 上传到 远程仓 
库。 同样， 在 回家的 路上， 不 用连接 VPN 你也可 以继续 工作。 换作 其他版 本控制 系统， 这 
么做 几平不 可能， 抑 或非常 麻烦。 比如 Perforce, 如果不 连到服 务器， 几乎 什么都 做不了 
( 译注： 默认 无法发 出命令 P4 edit file 开 始编辑 文件， 因为 Perforce 需要联 网通知 系统声 
明该 文件正 在被谁 修订。 但实际 上手工 修改文 件权限 可以绕 过这个 限制， 只是 完成后 还是无 
法提交 更新。 ） ； 如果是 Subversion 或 CVS, 虽然可 以编辑 文件， 但无 法提交 更新， 因 
为数据 库在网 络上。 看 上去好 像这些 都不是 什么大 问题， 但实际 体验过 之后， 你就会 惊喜地 
发现， 这 其实是 会带来 很大不 同的。 

1.3.3 时刻保 持数据 完整性 

在 保存到 Git 之前， 所有 数据都 要进行 内容的 校验和 （ checksum ) 计算， 并将此 结果作 
为数据 的唯一 标识和 索引。 换句 话说， 不 可能在 你修改 了文件 或目录 之后， Git —无 所知。 
这项特 性作为 Git 的设计 哲学， 建在 整体架 构的最 底层。 所以 如果文 件在传 输时变 得不完 
整， 或者磁 盘损坏 导致文 件数据 缺失， Git 都 能立即 察觉。 

Git 使用 SHA-1 算法 计算数 据的校 验和， 通 过对文 件的内 容或目 录的结 构计算 出一个 
SHA-1 哈 希值， 作为 指纹字 符串。 该 字串由 40 个 十六进 制字符 （ 0-9 及 a-f ) 组成， 看起 
来就 像是： 



24b9da6552252987aa493b52f8696cd6d3b00373 




Git 的工作 完全依 赖于这 类指纹 字串， 所以你 会经常 看到这 样的哈 希值。 实 际上， 所有保 
存在 Git 数据 库中的 东西都 是用此 哈希值 来作索 引的， 而不 是靠文 件名。 



1.3.4 多数操 作仅添 加数据 

常用的 Git 操作 大多仅 仅是把 数据添 加到数 据库。 因 为任何 一种不 可逆的 操作， 比 如删除 
数据， 都 会使回 退或重 现历史 版本变 得困难 重重。 在别的 VCS 中， 若还 未提交 更新， 就有 
可 能丢失 或者混 淆一些 修改的 内容， 但在 Git 里， 一旦提 交快照 之后就 完全不 用担心 丢失数 
据， 特别 是养成 定期推 送到其 他仓库 的习惯 的活。 
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这 种高可 靠性令 我们的 开发工 作安心 不少， 尽管去 做各种 试验性 的尝试 好了， 再怎 样也不 

会弄丢 数据。 至于 Git 内 部究竟 是如何 保存和 恢复数 据的， 我们会 在第九 章讨论 Git 内部原 
理 时再作 详述。 

1.3.5 文 件的三 种状态 

好， 现在请 注意， 接 下来要 讲的概 念非常 重要。 对于任 何一个 文件， 在 Git 内都只 有三种 
状态： 已提交 （committed ) , 已修改 （ modified ) 和 已暂存 （ staged ) 。 已提交 表示该 
文 件已经 被安全 地保存 在本地 数据库 中了； 已 修改表 示修改 了某个 文件， 但 还没有 提交保 
存； 已暂存 表示把 已修改 的文件 放在下 次提交 时要保 存的清 单中。 

由此我 们看到 Git 管理项 目时， 文件流 转的三 个工作 区域： Git 的工作 目录， 暂存 区域， 
以 及本地 仓库。 

Local Operations 




staging 
area 




git directory 
(repository) 



checkout the project 



F commit 



图 1.6: 工作 目录， 暂存 区域， 以及本 地仓库 



每个项 目都有 一个 Git 目录 （译注 ： 如果 git done 出来 的活， 就 是其中 .git 的 目录； 如果 
git clone -bare 的活， 新建的 目录本 身就是 Git 目录。 ） ， 它是 Git 用 来保存 元数据 和对象 
数 据库的 地方。 该目 录非常 重要， 每次克 隆镜像 仓库的 时候， 实 际拷贝 的就是 这个目 录里面 
的 数据。 

从 项目中 取出某 个版本 的所有 文件和 目录， 用 以开始 后续工 作的叫 做工作 目录。 这 些文件 
实际上 都是从 Git 目录中 的压縮 对象数 据库中 提取出 来的， 接下 来就可 以在工 作目录 中对这 
些文 件进行 编辑。 

所谓的 暂存区 域只不 过是个 简单的 文件， 一般 都放在 Git 目 录中。 有 时候人 们会把 这个文 
件叫 做索引 文件， 不过 标准说 法还是 叫暂存 区域。 
基本的 Git 工 作流程 如下： 

1. 在 工作目 录中修 改某些 文件。 

2. 对修改 后的文 件进行 快照， 然 后保存 到暂存 区域。 

3. 提交 更新， 将保存 在暂存 区域的 文件快 照永久 转储到 Git 目 录中。 

所以， 我们可 以从文 件所处 的位置 来判断 状态： 如果是 Git 目录中 保存着 的特定 版本文 
件， 就属于 已提交 状态； 如果作 了修改 并已放 入暂存 区域， 就属于 已暂存 状态； 如果 自上次 
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取 出后， 作了修 改但还 没有放 到暂存 区域， 就是 已修改 状态。 到第 二章的 时候， 我们 会进一 
步了 解其中 细节， 并学会 如何根 据文件 状态实 施后续 操作， 以 及怎样 跳过暂 存直接 提交。 

1.4 安装 Git 

是时 候动手 尝试下 Git 了， 不过得 先安装 好它。 有许多 种安装 方式， 主 要分为 两种， 一种 
是通过 编译源 代码来 安装； 另一 种是使 用为特 定平台 预编译 好的安 装包。 

1.4.1 从源代 码安装 

若 是条件 允许， 从源代 码安装 有很多 好处， 至少可 以安装 最新的 版本。 Git 的每 个版本 
都 在不断 尝试改 进用户 体验， 所 以能通 过源代 码自己 编译安 装最新 版本就 再好不 过了。 
有些 Linux 版本 自带的 安装包 更新起 来并不 及时， 所 以除非 你在用 最新的 distro 或者 
backports, 那么从 源代码 安装其 实该算 是最佳 选择。 

Git 的 工作需 要调用 curl, zlib, openssl, expat, libiconv 等库的 代码， 所以需 要先安 
装这 些依赖 工具。 在有 yum 的 系统上 （ 比如 Fedora ) 或者有 apt-get 的 系统上 （ 比如 
Debian 体系 ） ， 可以 用下面 的命令 安装： 

$ yum install curl-devel expat-devel gettext-devel \ 
openssl-devel zlib-devel 

$ apt-get install Iibcurl4-gnutls-dev Iibexpat1-dev gettext \ 
libz-dev libssl-dev 

之后， 从 下面的 Git 官方 站点下 载最新 版本源 代码： 

http://git-scm.com/download 

然后 编译并 安装： 

$ tar -zxf git-1.7.2.2.tar.gz 

$ cd git-1.7.2.2 

$ make prefix=/usr/local all 

$ sudo make prefix=/ usr/local install 

现 在已经 可以用 git 命 令了， 用 git 把 Git 项 目仓库 克隆到 本地， 以便日 后随时 更新： 

$ git clone git://g it.kernel.org/ pub/scm/g it/git. git 

1.4.2 在 Linux 上安装 

如 果要在 Linux 上安 装预编 译好的 Git 二 进制安 装包， 可以 直接用 系统提 供的包 管理工 
具。 在 Fedora 上用 yum 安装： 
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$ yum install git-core 



在 Ubuntu 这类 Debian 体 系的系 统上， 可以用 apt- get 安装: 



$ apt-get install git 



1.4.3 在 Mac 上安装 

在 Mac 上安装 Git 有两种 方式。 最容易 的当属 使用图 形化的 Git 安装 工具， 界 面如图 
1-7, 下载地 址在： 

http://code.google.eom/p/git-osx-installer 




图 1.7: Git OS X 安 装工具 

另―种 是通过 MacPortS ( http://www.macports.org ) 安装。 如 果已经 装好了 MacPortS, 
用下 面的命 令安装 Git: 



$ sudo port install git-core +svn +doc +bash — completion +gitweb 

这种方 式就不 需要再 自己安 装依赖 库了， Macports 会帮 你搞定 这些麻 烦事。 一般 上面列 
出的 安装选 项已经 够用， 要是 你想用 Git 连接 Subversion 的代码 仓库， 还可 以加上 +svn 
选项， 具体 将在第 八章作 介绍。 （ 译注： 还有一 种是 使用 homebrew ( https://github.com/ 
mxcl/homebrew ) ： brew install git。 ) 

1.4.4 在 Windows 上安装 

在 Windows 上安装 Git 同样 轻松， 有 个叫做 msysGit 的 项目提 供了安 装包， 可以到 
GitHub 的页面 上下载 exe 安装 文件并 运行： 

http://msysgit.github.com/ 

完 成安装 之后， 就可以 使用命 令行的 git 工具 （ 已经 自带了 ssh 客户端 ） 了， 另外 还有一 
个图形 界面的 Git 项 目管理 工具。 
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1.5 初 次运行 Git 前 的配置 

一般在 新的系 统上， 我们都 需要先 配置下 自己的 Git 工作 环境。 配置工 作只需 一次， 以后 
升 级时还 会沿用 现在的 配置。 当然， 如果 需要， 你 随时可 以用相 同的命 令修改 已有的 配置。 

Git 提 供了一 个叫做 git config 的工具 （译注 ： 实际是 g it- con fig 命令， 只 不过可 以通过 
git 加一个 名字来 呼叫此 命令。 ） ， 专 门用来 配置或 读取相 应的工 作环境 变量。 而正 是由这 
些环境 变量， 决定了 Git 在 各个环 节的具 体工作 方式和 行为。 这 些变量 可以存 放在以 下三个 
不同的 地方： 

□ /etc/gitconfig 文件： 系统 中对所 有用户 都普遍 适用的 配置。 若使用 git config 时用 -- 
system 选项， 读 写的就 是这个 文件。 

□ V.gitconfig 文件： 用户目 录下的 配置文 件只适 用于该 用户。 若使用 git config 时用 -- 
global 选项， 读 写的就 是这个 文件。 

□ 当前 项目的 git 目录 中的配 置文件 （也 就是 工作目 录中的 .git/ccmfig 文件） ： 这里的 
配 置仅仅 针对当 前项目 有效。 每一 个级别 的配置 都会覆 盖上层 的相同 配置， 所以 .git/ 

config 里 的配置 会覆盖 /etc/gitconfig 中 的同名 变量。 

在 Windows 系 统上， Git 会 找寻用 户主目 录下的 .gitccmfig 文件。 主 目录即 $HOME 变 
量 指定的 目录， 一般 都是 C:\Documents and Settings\$USER。 此外， Git 还会尝 试找寻 /etc/ 
gitconfig 文件， 只不过 看当初 Git 装 在什么 目录， 就以此 作为根 目录来 定位。 

1.5.1 用 户信息 

第一个 要配置 的是你 个人的 用户名 称和电 子邮件 地址。 这两条 配置很 重要， 每次 Git 提交 
时都 会引用 这两条 信息， 说 明是谁 提交了 更新， 所以会 随更新 内容一 起被永 久纳入 历史记 
录： 



$ git config 一一 global user. name "John Doe" 

$ git config 一一 global user. email johndoe@example.com 



如 果用了 一global 选项， 那么更 改的配 置文件 就是位 于你用 户主目 录下的 那个， 以 后你所 
有的 项目都 会默认 使用这 里配置 的用户 信息。 如 果要在 某个特 定的项 目中使 用其他 名字或 

者 电邮， 只 要去掉 一global 选项重 新配置 即可， 新的设 定保存 在当前 项目的 .git/config 文件 

里。 

1.5.2 文本 编辑器 

接 下来要 设置的 是默认 使用的 文本编 辑器。 Git 需要你 输入一 些额外 消息的 时候， 会自动 
调用一 个外部 文本编 辑器给 你用。 默认会 使用操 作系统 指定的 默认编 辑器， 一般可 能会是 
Vi 或者 Vim。 如果你 有其他 偏好， 比如 Emacs 的活， 可 以重新 设置： 



$ git config ― global core. editor emacs 
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1.5.3 差异分 析工具 

还有 一个比 较常用 的是， 在 解决合 并冲突 时使用 哪种差 异分析 工具。 比如 要改用 vimdiff 
的活： 



$ git config 一一 global merge. tool vimdiff 



Git 可以 理解 kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, 
和 opendiff 等合 并工具 的输出 信息。 当然， 你 也可以 指定使 用自己 开发的 工具， 具 体怎么 
做可以 参阅第 七章。 

1.5.4 查看配 置信息 

要检 查已有 的配置 信息， 可 以使用 git config -list 命令： 



$ git config ― list 

user.name=Scott Chacon 

use r.em a i 卜 schacon@gmail.com 

color.status=auto 

color.branch=auto 

color.interactive=auto 

color.di 幵 =auto 



有 时候会 看到重 复的变 量名， 那就说 明它们 来自不 同的配 置文件 （ 比如 /etc/gitconfig 和 
V.gitconfig ) , 不 过最终 Git 实际采 用的是 最后一 个。 

也可 以直接 查阅某 个环境 变量的 设定， 只要把 特定的 名字跟 在后面 即可， 像 这样： 



$ git config user. name 
Scott Chacon 



1.6 获 取帮助 

想了解 Git 的 各式工 具该怎 么用， 可以阅 读它们 的使用 帮助， 方法 有三: 



$ git help <verb> 
$ git <verb> ― help 
$ man git-<verb> 




比如， 要学习 config 命令 可以怎 么用， 运行: 
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$ git help config 



我们随 时都可 以浏览 这些帮 助信息 而无需 连网。 不过， 要是你 觉得还 不够， 可以到 

Frenode IRC 服务器 ( irc.freenode.net) 上的 #git 或 #github 频道寻 求他人 帮助。 这两个 
频道 上总有 着上百 号人， 大多 都有着 丰富的 git 知识， 并 且乐于 助人。 

1.7 小结 

至此， 你该对 Git 有了 点基本 认识， 包 括它和 以前你 使用的 CVCS 之间的 差别。 现在， 
在 你的系 统上应 该已经 装好了 Git, 设置了 自己的 名字和 电邮。 接 下来让 我们继 续学习 Git 
的基础 知识。 
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Git 基础 



读完 本章你 就能上 手使用 Git 了。 本章将 介绍几 个最基 本的， 也是最 常用的 Git 命令， 以 
后绝 大多数 时间里 用到的 也就是 这几个 命令。 读完 本章， 你就能 初始化 一个新 的代码 仓库， 
做一 些适当 配置； 开始或 停止跟 踪某些 文件； 暂 存或提 交某些 更新。 我们还 会展示 如何让 
Git 忽 略某些 文件， 或是 名称符 合特定 模式的 文件； 如何 既快且 容易地 撤消犯 下的小 错误； 
如何浏 览项目 的更新 历史， 查 看某两 次更新 之间的 差异； 以及如 何从远 程仓库 拉数据 下来或 
者 推数据 上去。 

2.1 取得 项目的 Git 仓库 

有两 种取得 Git 项目 仓库的 方法。 第一种 是在现 存的目 录下， 通过导 入所有 文件来 创建新 
的 Git 仓库。 第二 种是从 已有的 Git 仓库克 隆出一 个新的 镜像仓 库来。 

2.1.1 在工作 目录中 初始化 新仓库 

要对现 有的某 个项目 开始用 Git 管理， 只需到 此项目 所在的 目录， 执行： 



$ git init 



初始 化后， 在当 前目录 下会出 现一个 名为. git 的 目录， 所有 Git 需要 的数据 和资源 都存放 
在 这个目 录中。 不过 目前， 仅 仅是按 照既有 的结构 框架初 始化好 了里边 所有的 文件和 目录， 
但 我们还 没有开 始跟踪 管理项 目 中的任 何一个 文件。 （ 在 第九章 我们会 详细说 明刚才 创建的 
.git 目录 中究竟 有哪些 文件， 以 及都起 些什么 作用。 ） 

如果当 前目录 下有几 个文件 想要纳 入版本 控制， 需 要先用 git add 命 令告诉 Git 开 始对这 
些文 件进行 跟踪， 然后 提交： 

$ git add *.c 

$ git add README 

$ git commit -m 'initial project version' 

稍后 我们再 逐一解 释每条 命令的 意思。 不过 现在， 你已 经得到 了一个 实际维 护着若 干文件 

的 Git 仓库。 
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2.1.2 从 现有仓 库克隆 

如果想 对某个 开源项 目出一 份力， 可以 先把该 项目的 Git 仓库复 制一份 出来， 这 就需要 
用到 git clone 命令。 如果 你熟悉 其他的 VCS 比如 Subversion, 你可 能已经 注意到 这里使 
用的是 done 而不是 checkout. 这是 个非常 重要的 差别， Git 收 取的是 项目历 史的所 有数据 
(每一 个文件 的每一 个版本 ） ， 服 务器上 有的数 据克隆 之后本 地也都 有了。 实 际上， 即便服 
务 器的磁 盘发生 故障， 用任 何一个 克隆出 来的客 户端都 可以重 建服务 器上的 仓库， 回 到当初 
克隆时 的状态 （ 虽 然可能 会丢失 某些服 务器端 的挂钩 设置， 但 所有版 本的数 据仍旧 还在， 有 
关细节 请参考 第四章 ） 。 

克 隆仓库 的命令 格式为 git clone [uH]。 比如， 要克隆 Ruby 语言的 Git 代 码仓库 Grit, 可 
以用 下面的 命令： 



$ git clone git://g ithub.com/schacon/grit.git 



这会 在当前 目录下 创建一 个名为 grit 的 目录， 其中包 含一个 .git 的 目录， 用 于保存 下载下 
来的所 有版本 记录， 然 后从中 取出最 新版本 的文件 拷贝。 如果进 入这个 新建的 gHt 目录， 你 

会看到 项目中 的所有 文件已 经在里 边了， 准备好 后续的 开发和 使用。 如果希 望在克 隆的时 
候， 自己定 义要新 建的项 目目录 名称， 可以 在上面 的命令 末尾指 定新的 名字： 



$ git clone git://g ithub.com/schacon/grit.git mygrit 



唯一 的差别 就是， 现在新 建的目 录成了 mygrit, 其他 的都和 上边的 一样。 

Git 支持 许多数 据传输 协议。 之前的 例子使 用的是 git:// 协议， 不 过你也 可以用 http(s):// 

或者 USer @ Server: / P ath.git 表示的 SSH 传输 协议。 我们会 在第四 章详细 介绍所 有这些 协议在 

服务器 端该如 何配置 使用， 以及各 种方式 之间的 利弊。 

2.2 记录每 次更新 到仓库 

现在 我们手 上已经 有了一 个真实 项目的 Git 仓库， 并 从这个 仓库中 取出了 所有文 件的工 
作 拷贝。 接 下来， 对 这些文 件作些 修改， 在完 成了一 个阶段 的目标 之后， 提交 本次更 新到仓 

库。 

请 记住， 工作目 录下面 的所有 文件都 不外乎 这两种 状态： 已跟 踪或未 跟踪。 已跟踪 的文件 
是指本 来就被 纳入版 本控制 管理的 文件， 在 上次快 照中有 它们的 记录， 工作 一段时 间后， 它 
们的 状态可 能是未 更新， 已修改 或者已 放入暂 存区。 而 所有其 他文件 都属于 未跟踪 文件。 它 
们 既没有 上次更 新时的 快照， 也不 在当前 的暂存 区域。 初 次克隆 某个仓 库时， 工作目 录中的 
所 有文件 都属于 已跟踪 文件， 且状 态为未 修改。 

在编 辑过某 些文件 之后， Git 将这 些文件 标为已 修改。 我们逐 步把这 些修改 过的文 件放到 
暂存 区域， 直到最 后一次 性提交 所有这 些暂存 起来的 文件， 如此 重复。 所 以使用 Git 时的文 
件状态 变化周 期如图 2-1 所示。 

2.2.1 检查 当前文 件状态 

要 确定哪 些文件 当前处 于什么 状态， 可以用 git status 命令。 如果在 克隆仓 库之后 立即执 
行此 命令， 会看 到类似 这样的 输出： 
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File Status Lifecycle 




图 2.1: 文件的 状态变 化周期 



$ git status 

# On branch master 

nothing to commit (working directory clean) 

这 说明你 现在的 工作目 录相当 干净。 换句 活说， 所有已 跟踪文 件在上 次提交 后都未 被更改 
过。 此外， 上面的 信息还 表明， 当前目 录下没 有出现 任何处 于未跟 踪的新 文件， 否则 Git 会 
在 这里列 出来。 最后， 该命令 还显示 了当前 所在的 分支是 master, 这 是默认 的分支 名称， 实 
际是 可以修 改的， 现在 先不用 考虑。 下一 章我们 就会详 细讨论 分支和 引用。 

现在让 我们用 vim 创建一 个 新文件 README, 保 存退出 后运行 git status 会看到 该文件 
出现在 未跟踪 文件列 表中： 

$ vim README 
$ git status 

# On branch master 

# Untracked files: 

# (use "git add <file>..." to include in what will be committed ) 

# 

# README 

nothing added to commit but untracked files present ( use "git add" to track) 

在 状态报 告中可 以看到 新建的 Readme 文件 出现在 "Untracked files" 下面。 未跟 踪的文 
件 意味着 Git 在之前 的快照 （提交 ） 中没 有这些 文件； Git 不 会自动 将之纳 入跟踪 范围， 除 
非 你明明 白白地 告诉它 "我 需要 跟踪该 文件" ， 因 而不用 担心把 临时文 件什么 的也归 入版本 
管理。 不过现 在的例 子中， 我 们确实 想要跟 踪管理 README 这个 文件。 

2.2.2 跟踪 新文件 

使 用命令 git add 开 始跟踪 一个新 文件。 所以， 要跟踪 README 文件， 运行： 
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$ git add README 



此时 再运行 git status 命令， 会看到 README 文 件已被 跟踪， 并处 于暂存 状态: 



$ git status 




# On branch master 




# Changes to be committed: 




# (use "git reset HEAD <file>..." to u 


nstage) 


# 




# new file: README 




# 





只要在 "Changes to be committed" 这行下 面的， 就 说明是 已暂存 状态。 如果 此时提 
交， 那么 该文件 此时此 刻的版 本将被 留存在 历史记 录中。 你可能 会想起 之前我 们使用 gitinit 
后就 运行了 git add 命令， 开 始跟踪 当前目 录下的 文件。 在 git add 后 面可以 指明要 跟踪的 
文件 或目录 路径。 如果 是目录 的活， 就说明 要递归 跟踪该 目录下 的所有 文件。 （译注 ： 其实 
git add 的潜 台词就 是把目 标文件 快照放 入暂存 区域, 也就是 add file into staged area, 同 
时未 曾跟踪 过的文 件标记 为需要 跟踪。 这样 就好理 解后续 add 操作的 实际意 义了。 ） 

2.2.3 暂 存已修 改文件 

现 在我们 修改下 之前已 跟踪过 的文件 benchmarks.rb, 然后再 次运行 status 命令， 会看到 
这样 的状态 报告： 

$ git status 

# On branch master 

# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 

# 

# new file: README 

# 

# Changes not staged for commit: 

# (use "git add <file>..." to update what will be committed ) 
# 

# modified: benchmarks. rb 
# 



文件 benchmarks.rb 出现在 "Changes not staged for commit" 这行 下面， 说 明已跟 
踪文件 的内容 发生了 变化， 但 还没有 放到暂 存区。 要暂 存这次 更新， 需 要运行 git add 命令 
(这 是个 多功能 命令， 根据目 标文件 的状态 不同， 此 命令的 效果也 不同： 可以 用它开 始跟踪 
新 文件， 或者把 已跟踪 的文件 放到暂 存区， 还能用 于合并 时把有 冲突的 文件标 记为已 解决状 
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态等 ） 。 现 在让我 们运行 git add 将 benchmarks.rb 放到暂 存区， 然后 再看看 git status 的 
输出： 



$ git add benchmarks.rb 




$ git status 




# On branch master 




# Changes to be committed: 




# (use "git reset HEAD <file>..." to u 


nstage) 


# 




# new file: README 




# modified: benchmarks.rb 




# 





现在 两个文 件都已 暂存， 下次提 交时就 会一并 记录到 仓库。 假设 此时， 你 想要在 benchmarks.rb 
里 再加条 注释， 重新 编辑存 盘后， 准备好 提交。 不过 且慢， 再运行 git status 看看： 



$ vim benchmarks.rb 
$ git status 

# On branch master 

# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 
# 

# new file: README 

# modified: benchmarks.rb 
# 

# Changes not staged for commit: 

# (use "git add <file>..." to update what will be committed ) 

# 

# modified: benchmarks.rb 
# 



怎么 回事？ benchmarks.rb 文 件出现 了两次 ！ 一 次算未 暂存， 一 次算已 暂存， 这怎 么可能 
呢？ 好吧， 实际上 Git 只不过 暂存了 你运行 git add 命 令时的 版本， 如 果现在 提交， 那么提 
交的是 添加注 释前的 版本， 而 非当前 工怍目 录中的 版本。 所以， 运行了 git add 之后 又作了 
修订的 文件， 需要重 新运行 git add 把最新 版本重 新暂存 起来： 

$ git add benchmarks.rb 
$ git status 

# On branch master 

# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 
# 
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# new file: README 

# modified: benchmarks. rb 
# 



2.2.4 忽略某 些文件 

一般 我们总 会有些 文件无 需纳入 Git 的 管理， 也不希 望它们 总出现 在未跟 踪文件 列表。 通 
常都是 些自动 生成的 文件， 比 如日志 文件， 或 者编译 过程中 创建的 临时文 件等。 我们 可以创 
建一 个名为 .gitignore 的 文件， 列出 要忽略 的文件 模式。 来 看一个 实际的 例子： 



$ cat .gitignore 
Moa] 



第一 行告诉 Git 忽略 所有以 .0 或 .a 结尾的 文件。 一 般这类 对象文 件和存 档文件 都是编 
译过 程中出 现的， 我 们用不 着跟踪 它们的 版本。 第二 行告诉 Git 忽略 所有以 波浪符 （~) 
结尾的 文件， 许多 文本编 辑软件 （比如 Emacs) 都 用这样 的文件 名保存 副本。 此外， 你可 
能还需 要忽略 log, tm P 或者 P id 目录， 以及自 动生成 的文档 等等。 要 养成一 开始就 设置好 
■gitignore 文件的 习惯， 以免将 来误提 交这类 无用的 文件。 

文件 .gitignore 的格 式规范 如下： 

□ 所有 空行或 者以注 释符号 # 开 头的行 都会被 Git 忽略。 

□ 可 以使用 标准的 glob 模式 匹配。 

□ 匹 配模式 最后跟 反斜杠 （/) 说 明要忽 略的是 目录。 

□ 要 忽略指 定模式 以外的 文件或 目录， 可以 在模式 前加上 惊叹号 （！） 取反。 

所谓的 glob 模 式是指 shell 所使 用的简 化了的 正则表 达式。 星号 （ * ) 匹配 零个或 多个任 
意 字符； [abc] 匹配任 何一个 列在方 括号中 的字符 （这 个例子 要么匹 配一个 a, 要么匹 配一个 
b, 要么匹 配一个 c ) ； 问号 （ ？ ） 只 匹配一 个任意 字符； 如果在 方括号 中使用 短划线 分隔两 
个 字符， 表 示所有 在这两 个字符 范围内 的都可 以匹配 （ 比如 [0-9] 表示匹 配所有 0 到 9 的数 
字） 。 

我们再 看一个 .gitignore 文件的 例子： 



# 此为 注释： ：将被 Git 忽略 

*.a # 忽 略所有 .a 结尾 的文件 

！ lib.a # 但 lib.a 除外 

/TODO # 仅仅 忽略项 目根目 录下的 TODO 文件， 不包括 subdir/TODO 
build/ # 忽略 build/ 目录 下的所 有文件 

doc/*.txt # 会忽略 doc/notes.txt 但 不包括 doc/server/arch.txt 
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2.2.5 查看已 暂存和 未暂存 的更新 

实际上 git status 的显 示比较 简单， 仅 仅是列 出了修 改过的 文件， 如 果要查 看具体 修改了 
什么 地方， 可以用 git diff 命令。 稍后我 们会详 细介绍 git diff, 不过 现在， 它 已经能 回答我 
们的 两个问 题了： 当前 做的哪 些更新 还没有 暂存？ 有哪些 更新已 经暂存 起来准 备好了 下次提 
交？ git diff 会 使用文 件补丁 的格式 显示具 体添加 和删除 的行。 

假如再 次修改 README 文件后 暂存， 然 后编辑 benchmarks.rb 文件 后先别 暂存， 运行 status 
命 令将会 看到： 



$ git status 

# On branch master 

# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 
# 

# new file: README 

# 

# Changes not staged for commit: 

# (use "git add <file>..." to update what will be committed ) 
# 

# modified: benchmarks. rb 
# 



要查看 尚未暂 存的文 件更新 了哪些 部分， 不加 参数直 接输入 git diff: 



$ git diff 

diff -- git a/benchmarks. rb b/benchmarks.rb 

index 3cb747f..da65585 100644 

— a/benchmarks. rb 

+++ b/benchmarks.rb 

@@ -36,6 +36,10 @@ def main 

@commit.parents[0].parents[0].parents[0] 
end 



run_code(x, 'commits 1') do 

git.commits.size 
end 



run_code(x, 'commits 2') do 
log = g it.com m its ('master', 15) 
log. size 




此命 令比较 的是工 作目录 中当前 文件和 暂存区 域快照 之间的 差异， 也 就是修 改之后 还没有 
暂 存起来 的变化 内容。 
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若要看 已经暂 存起来 的文件 和上次 提交时 的快照 之间的 差异， 可以用 git diff -cached 命 
令。 （Git 1.6.1 及 更高版 本还允 许使用 git diff —staged, 效 果是相 同的， 但更好 记些。 ） 来 
看看 实际的 效果： 

$ git diff ― cached 

diff —git a/README b/README 

new file mode 100644 

index 0000000..03902a1 

— /dev/null 

+++ b/README2 

@@ -0,0 +1,5 @@ 

+grit 

+ by Tom Preston-Werner, Chris Wanstrath 
+ http://github.com/mojombo/grit 

+Grit is a Ruby library for extracting information from a Git repository 

请 注意， 单单 git diff 不 过是显 示还没 有暂存 起来的 改动， 而不 是这次 工作和 上次提 交之间 
的 差异。 所 以有时 候你一 下子暂 存了所 有更新 过的文 件后， 运行 git diff 后却 什么也 没有， 
就 是这个 原因。 

像之前 说的， 暂存 benchmarks.rb 后再 编辑， 运行 git status 会看 到暂存 前后的 两个版 
本： 

$ git add benchmarks.rb 

$ echo '# test line' » benchmarks.rb 

$ git status 

# On branch master 

# 

# Changes to be committed: 

# 

# modified: benchmarks.rb 
# 

# Changes not staged for commit: 

# 

# modified: benchmarks.rb 
# 



现 在运行 git diff 看暂存 前后的 变化： 
$ git diff 

diff 一一 git a/benchmarks. rb b/benchmarks.rb 
index e445e28..86b2f7c 100644 
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— a/benchmarks. rb 
+++ b/benchmarks.rb 
@@ -127,3 +127,4 @@ end 
main ( ) 



##pp Grit::GitRuby.cache_client.stats 
+# test tine 



然后用 git diff -cached 查看已 经暂存 起来的 变化： 


$ git diff -- cached 




diff 一一 git a/benchmarks. rb b/benchmarks.rb 




index 3cb747f..e445e28 100644 




— a/benchmarks. rb 




+++ b/benchmarks.rb 




@@ -36,6 +36,10 @@ def main 




@commit.parents[0].parents[0].parents[0] 




end 




+ run— code(x， 'commits 1') do 




+ git.commits.size 




+ end 




run_code(x, 'commits 2') do 




log = git.commits(' master', 15) 




log. size 





2.2.6 提 交更新 

现 在的暂 存区域 已经准 备妥当 可以提 交了。 在此 之前， 请一定 要确认 还有什 么修改 过的或 

新建 的文件 还没有 git add 过， 否则 提交的 时候不 会记录 这些还 没暂存 起来的 变化。 所以， 
每次 准备提 交前， 先用 git status 看下， 是不 是都已 暂存起 来了， 然后再 运行提 交命令 git 

commit: 



$ git commit 



这种方 式会启 动文本 编辑器 以便输 入本次 提交的 说明。 （默认 会启用 shell 的环 境变量 
$EDlTOR 所 指定的 软件， 一 般都是 vim 或 ema CS 。 当 然也可 以按照 第一章 介绍的 方式， 使 
用 git config -global core.editor 命 令设定 你喜欢 的编辑 软件。 ） 

编辑器 会显示 类似下 面的文 本信息 （本 例选用 Vim 的屏 显方式 展示） ： 
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# Please enter the commit message for your changes. Lines starting 

# with will be ignored, and an empty message aborts the commit. 

# On branch master 

# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 
# 

# new file: README 

# modified: benchmarks. rb 



'.git/COMMIT_EDITMSG" 10L, 283C 



可以 看到， 默认的 提交消 息包含 最后一 次运行 git status 的 输出， 放 在注释 行里， 另外开 
头 还有一 空行， 供你输 入提交 说明。 你 完全可 以去掉 这些注 释行， 不过留 着也没 关系， 多少 
能帮 你回想 起这次 更新的 内容有 哪些。 （如 果觉 得这还 不够， 可以用 -v 选项 将修改 差异的 
每一行 都包含 到注释 中来。 ） 退 出编辑 器时， Git 会 丢掉注 释行， 将说 明内容 和本次 更新提 
交到 仓库。 

另外也 可以用 -m 参数后 跟提交 说明的 方式， 在一 行命令 中提交 更新： 



$ git commit -m "Story 182: Fix benchmarks for speed" 
[master]: created 463dc4f: "Fix benchmarks for speed" 

2 files changed, 3 insertions( + ), 0 deletions ( — ) 

create mode 100644 README 

好， 现 在你已 经创建 了第一 个提交 ！ 可以 看到， 提交后 它会告 诉你， 当前 是在哪 个分支 
(master) 提 交的， 本 次提交 的完整 SHA-1 校验和 是什么 （ 463dc4f ) , 以 及在本 次提交 
中， 有多少 文件修 订过， 多 少行添 改和删 改过。 

记住， 提交 时记录 的是放 在暂存 区域的 快照， 任何 还未暂 存的仍 然保持 已修改 状态， 可以 
在 下次提 交时纳 入版本 管理。 每 一次运 行提交 操作， 都是对 你项目 作一次 快照， 以后 可以回 
到这个 状态， 或 者进行 比较。 

2.2.7 跳过 使用暂 存区域 

尽管使 用暂存 区域的 方式可 以精心 准备要 提交的 细节， 但有时 候这么 做略显 繁琐。 Git 提 
供 了一个 跳过使 用暂存 区域的 方式， 只要在 提交的 时候， 给 git commit 加上 -a 选项， Git 就 
会自 动把所 有已经 跟踪过 的文件 暂存起 来一并 提交， 从 而跳过 git add 步骤： 



$ git status 

# On branch master 

# 



22 



Scott Chacon Pro Git 



2.2 节 记录每 次更新 到仓库 



# Changes not staged for commit: 
# 

# modified: benchmarks. rb 

# 

$ git commit - a -m 'added new benchmarks' 
[master 83e38c7] added new benchmarks 
1 files changed, 5 insertions( + ), 0 deletions (-) 



看到 了吗？ 提交 之前不 再需要 git add 文件 benchmarks.rb 了。 
2.2.8 移 除文件 

要从 Git 中移 除某个 文件， 就必须 要从已 跟踪文 件清单 中移除 （ 确切 地说， 是从暂 存区域 
移除 ）， 然后 提交。 可以用 git rm 命令完 成此项 工作， 并连带 从工作 目录中 删除指 定的文 
件， 这 样以后 就不会 出现在 未跟踪 文件清 单中了 。 

如果 只是简 单地从 工作目 录中手 工删除 文件， 运行 git status 时 就会在 "Changes not 
staged for commit" 部分 （ 也 就是- 未暂存 -清单 ） 看到： 



$ rm grit.gemspec 
$ git status 

# On branch master 
# 

# Changes not staged for commit: 

# (use "git add/ rm <file>..." to update what will be committed ) 

# 

# deleted: grit.gemspec 
# 



然后 再运行 git rm 记录此 次移除 文件的 操作: 



$ git rm grit.gemspec 
rm 'grit.gemspec' 
$ git status 

# On branch master 

# 

# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 
# 

# deleted: grit.gemspec 
# 
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最后 提交的 时候， 该文 件就不 再纳入 版本管 理了。 如果 删除之 前修改 过并且 已经放 到暂存 

区域 的话， 则必 须要用 强制删 除选项 -f ( 译注： 即 force 的 首字母 ） ， 以防误 删除文 件后丢 
失 修改的 内容。 

另外 一种情 况是， 我 们想把 文件从 Git 仓库 中删除 （ 亦即从 暂存区 域移除 ） ， 但仍 然希望 
保留 在当前 工作目 录中。 换句 活说， 仅是 从跟踪 清单中 删除。 比 如一些 大型日 志文件 或者一 
堆 .a 编译 文件， 不小心 纳入仓 库后， 要移除 跟踪但 不删除 文件， 以便 稍后在 -gitignore 文件 
中 补上, 用 -cached 选项 即可： 



$ git rm ― cached readme.txt 



后 面可以 列出文 件或者 目录的 名字， 也可 以使用 glob 模式。 比 方说: 



$ git rm log/\*.log 

注意 到星号 * 之前的 反斜杠 \, 因为 Git 有 它自己 的文件 模式扩 展匹配 方式， 所以 我们不 

用 shell 来帮 忙展开 （译注 ： 实际 上不加 反斜杠 也可以 运行， 只不 过按照 shell 扩展 的活， 

仅仅 删除指 定目录 下的文 件而不 会递归 匹配。 上面 的例子 本来就 指定了 目录， 所以 效果等 

同， 但 下面的 例子就 会用递 归方式 匹配， 所以必 须加反 斜杠。 ） 。 此 命令删 除所有 log/ 目 
录下扩 展名为 .log 的 文件。 类似的 比如： 



$ git rm \ 



会递 归删除 当前目 录及其 子目录 中所有 ~ 结尾的 文件。 

2.2.9 移 动文件 

不像 其他的 VCS 系统， Git 并不 跟踪文 件移动 操作。 如果在 Git 中 重命名 了某个 文件， 
仓库中 存储的 元数据 并不会 体现出 这是一 次改名 操作。 不过 Git 非常 聪明， 它 会推断 出究竟 
发生了 什么， 至于 具体是 如何做 到的， 我 们稍后 再谈。 

既然 如此， 当 你看到 Git 的 mv 命令 时一定 会困惑 不已。 要在 Git 中 对文件 改名， 可以这 
么做： 



$ git mv file— from file-to 



它会怡 如预期 般正常 工作。 实 际上， 即便 此时查 看状态 信息， 也会明 白无误 地看到 关于重 
命名 操怍的 说明： 

$ git mv README.txt README 
$ git status 
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# On branch master 

# Your branch is ahead of 'origin/ master' by 1 commit. 

# 

# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 
# 

# renamed: README.txt -> README 

# 

其实， 运行 git mv 就相 当于运 行了下 面三条 命令: 

$ mv README.txt README 
$ git rm README.txt 
$ git add README 



如 此分开 操作， Git 也会意 识到这 是一次 改名， 所以不 管何种 方式都 一样。 当然， 直接用 
git mv 轻便 得多， 不过有 时候用 其他工 具批处 理改名 的活， 要 记得在 提交前 删除老 的文件 

名， 再添加 新的文 件名。 

2.3 查看提 交历史 

在提 交了若 干更新 之后， 又或 者克隆 了某个 项目， 想回顾 下提交 历史， 可 以使用 git log 
命令 查看。 

接 下来的 例子会 用我专 门用于 演示的 simplegit 项目， 运行 下面的 命令获 取该项 目源代 
码： 

git clone git://github.com/schacon/simpleg it-prog it.git 



然后在 此项目 中运行 git log, 应该 会看到 下面的 输出: 

$ git log 

commit ca82a6dff817ec66f44342007202690a93763949 
Author: Scott Chacon <schacon@gee-mail.com> 
Date: Mon Mar 17 21:52:11 2008 -0700 

changed the version number 

commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 
Author: Scott Chacon <schacon@gee-mail.com> 
Date: Sat Mar 15 16:40:33 2008 -0700 
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removed unnecessary test code 

commit a1 1 bef06a3f659402fe7563abf99ad00de2209e6 
Author: Scott Chacon <schacon@gee-mail.com> 
Date: Sat Mar 15 10:31:28 2008 -0700 

first commit 



默认 不用任 何参数 的话， git log 会按 提交时 间列出 所有的 更新， 最近 的更新 排在最 上面。 
看到 了吗， 每次 更新都 有一个 SHA-1 校 验和、 作 者的名 字和电 子邮件 地址、 提交 时间， 最 
后縮 进一个 段落显 示提交 说明。 

git log 有 许多选 项可以 帮助你 搜寻感 兴趣的 提交， 接 下来我 们介绍 些最常 用的。 
我 们常用 -P 选 项展开 显示每 次提交 的内容 差异， 用 -2 则仅显 示最近 的两次 更新： 

$ git log - p -2 

commit ca82a6dff817ec66f44342007202690a93763949 
Author: Scott Chacon <schacon@gee-mail.com> 
Date: Mon Mar 17 21:52:11 2008 -0700 

changed the version number 

diff —git a/Rakefile b/Rakefile 
index a874b73..8f94139 100644 
— a/Rakefile 
+++ b/Rakefile 

@@ -5,7 +5,7 @@ require 'rake/gempackagetask' 
spec = Gem::Specification.new do Isl 
- s. version = "0.1.0" 
+ s.version = "0.1.1" 

s. author = "Scott Chacon" 

commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 
Author: Scott Chacon <schacon@gee-mail.com> 
Date: Sat Mar 15 16:40:33 2008 -0700 

removed unnecessary test code 

diff —― git a/lib/simplegit.rb b/lib/simplegit.rb 
index a0a60ae..47c6340 100644 
— a/lib/simplegit.rb 
+++ b/lib/simplegit.rb 
@@ -18,8 +18,3 @@ class SimpleGit 
end 
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end 

-if $0 == __FILE__ 
- git = SimpleGit.new 
- puts git.show 
-end 

\ No newline at end of file 



在 做代码 审查， 或者 要快速 浏览其 他协作 者提交 的更新 都怍了 哪些改 动时， 就可以 用这个 
选项。 此外， 还有许 多摘要 选项可 以用， 比如 --stat, 仅 显示简 要的增 改行数 统计： 

$ git log —stat 

commit ca82a6dff817ec66f44342007202690a93763949 
Author: Scott Chacon <schacon@gee-mail.com> 
Date: Mon Mar 17 21:52:11 2008 -0700 

changed the version number 

Rakefile I 2 +- 

1 files changed, 1 insertions( + ), 1 deletions ( — ) 

commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 
Author: Scott Chacon <schacon@gee-mail.com> 
Date: Sat Mar 15 16:40:33 2008 -0700 

removed unnecessary test code 

lib/simplegit.rb I 5 

1 files changed, 0 insertions( + ), 5 deletions (-) 

commit a1 1 bef06a3f659402fe7563abf99ad00de2209e6 
Author: Scott Chacon <schacon@gee-mail.com> 
Date: Sat Mar 15 10:31:28 2008 -0700 

first commit 

README I 6 ++++++ 

Rakefile I 23 +++++++++++++++++++++++ 

3 files changed, 54 insertions( + ), 0 deletions ( — ) 

每个提 交都列 出了修 改过的 文件， 以 及其中 添加和 移除的 行数， 并 在最后 列出所 有增减 

行数 小计。 还有个 常用的 一pretty 选项， 可以指 定使用 完全不 同于默 认格式 的方式 展示提 



27 



第 2 章 Git 基础 



Scott Chacon Pro Git 



交 历史。 比如用 oneline 将每个 提交放 在一行 显示， 这 在提交 数很大 时非常 有用。 另 外还有 
short, full 和 fuller 可 以用， 展示 的信息 或多或 少有些 不同， 请 自己动 手实践 一下看 看效果 

如何。 

$ git log ― pretty=oneline 

Ca82a6dff817ec66f44342007202690a93763949 changed the version number 
085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 removed unnecessary test code 
a11bef06a3f659402fe7563abf99ad00de2209e6 first commit 



但 最有意 思的是 format, 可 以定制 要显示 的记录 格式， 这样 的输出 便于后 期编程 提取分 
析， 像 这样： 



$ git log 


— pretty=format:"%h - %an, %ar : 


0 /oS" 


ca82a6d 


- Scott Chacon, 11 months ago 


: changed the version number 


085bb3b 


- Scott Chacon, 11 months ago 


: removed unnecessary test code 


allbefO - 


- Scott Chacon, 1 1 months ago : 


first commit 



表 2-1 列出了 常用的 格式占 位符写 法及其 代表的 意义。 



选项 


说明 


%H 


提 交对象 （commit) 的 完整哈 希字串 


%h 


提交 对象的 简短哈 希字串 


%T 


树对象 （tree) 的 完整哈 希字串 


%t 


树 对象的 简短哈 希字串 


%P 


父对象 （ parent ) 的 完整哈 希字串 


%p 


父 对象的 简短哈 希字串 


%an 


作者 （author) 的名字 


%ae 


作者的 电子邮 件地址 


%ad 


作者修 订日期 （ 可以用 -date= 选项定 制格式 ） 


%ar 


作 者修订 日期， 按 多久以 前的方 式显示 


%cn 


提交者 （committer) 的名字 


%ce 


提 交者的 电子邮 件地址 


%cd 


提 交日期 


%cr 


提交 日期， 按 多久以 前的方 式显示 


%s 


提 交说明 



表 2.1: 



你一 定奇怪 -作者 （author) 和 提交者 （committer) - 之间究 竟有何 差别， 其实作 者指的 
是 实际作 出修改 的人， 提 交者指 的是最 后将此 工作成 果提交 到仓库 的人。 所以， 当你 为某个 
项 目发布 补丁， 然 后某个 核心成 员将你 的补丁 并入项 目时， 你就是 作者， 而那 个核心 成员就 
是提 交者。 我 们会在 第五章 再详细 介绍两 者之间 的细 微差别 。 

用 oneline 或 format 时结合 一graph 选项， 可以 看到开 头多出 一些 ASCII 字符串 表示的 
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简单 图形， 形象地 展示了 每个提 交所在 的分支 及其分 化衍合 情况。 在我 们之前 提到的 Grit 
项 目仓库 中可以 看到： 

$ git log ― pretty=format:"%h %s" ― graph 

* 2d3acf9 ignore errors from SIGCHLD on trap 

* 5e3ee1 1 Merge branch 'master' of git://github.com/dustin/grit 
l\ 

I * 420eac9 Added a method for getting the current branch. 

* I 30e367c timeout code and tests 

* I 5a09431 add timeout protection to grit 

* I e1 193f8 support for heads with slashes in them 
1/ 

* d6016bc require time for xmlschema 

* 1 1d191e Merge branch 'defunkt' into local 



以上 只是简 单介绍 了一些 git log 命令 支持的 选项。 表 2-2 还 列出了 一些其 他常用 的选项 
及其 释义。 

选项 说明 

- P 按补 丁格式 显示每 个更新 之间的 差异。 

-stat 显 示每次 更新的 文件修 改统计 信息。 

-shortstat 只显示 一stat 中最后 的行数 修改添 加移除 统计。 

-name-only 仅在提 交信息 后显示 已修改 的文件 清单。 

-name-status 显示 新增、 修改、 删除 的文件 清单。 

-abbrev-commit 仅显示 SHA-1 的 前几个 字符， 而非 所有的 40 个 字符。 
—relative-date 使用 较短的 相对时 间显示 （ 比如， "2 weeks ago" ) 。 
-graph 显示 ASCII 图形表 示的分 支合并 历史。 

—pretty 使用其 他格式 显示历 史提交 信息。 可 用的选 项包括 oneline, short, full, fuller 禾口 format (后跟 
指 定格式 ） 。 



2.3.1 限制输 出长度 

除了 定制输 出格式 的选项 之外， git log 还 有许多 非常实 用的限 制输出 长度的 选项， 也就是 
只 输出部 分提交 信息。 之前我 们已经 看到过 -2 了， 它只显 示最近 的两条 提交， 实 际上， 这 
是- <n> 选项的 写法， 其中的 n 可以是 任何自 然数， 表示 仅显示 最近的 若干条 提交。 不过实 
践中 我们是 不太用 这个选 项的， Git 在输 出所有 提交时 会自动 调用分 页程序 （less) , 要看 

更早 的更新 只需翻 到下页 即可。 

另外还 有按照 时间作 限制的 选项， 比如 一since 和 一 U ntil。 下 面的命 令列出 所有最 近两周 
内的 提交： 

$ git log ― since=2. weeks 
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你可以 给出各 种时间 格式， 比如说 具体的 某一天 （ "2008-01-15" ) , 或 者是多 久以前 
( "2 years 1 day 3 minutes ago" ) 。 

还可以 给出若 干搜索 条件， 列出 符合的 提交。 用 一author 选项显 示指定 作者的 提交， 用 
-grep 选项 搜索提 交说明 中的关 键字。 （请 注意， 如果要 得到同 时满足 这两个 选项搜 索条件 
的 提交， 就 必须用 一all-match 选项。 否则， 满足 任意一 个条 件的提 交都会 被匹配 出来） 

另一 个真正 实用的 git log 选项 是路径 (path), 如 果只关 心某些 文件或 者目录 的历史 提交， 
可以在 git log 选 项的最 后指定 它们的 路径。 因为 是放在 最后位 置上的 选项， 所以用 两个短 
划线 （一） 隔开 之前的 选项和 后面限 定的路 径名。 

表 2-3 还列 出了其 他常用 的类似 选项。 



选项 说明 

-(n) 仅显示 最近的 n 条提交 
-since, --after 仅 显示指 定时间 之后的 提交。 
-until, -before 仅 显示指 定时间 之前的 提交。 
-author 仅 显示指 定作者 相关的 提交。 
-committer 仅显 示指定 提交者 相关的 提交。 

来 看一个 实际的 例子， 如果 要查看 Git 仓 库中， 2008 年 10 月 期间， junioHamano 提 
交的 但未合 并的测 试脚本 （位于 项目的 t/ 目 录下的 文件） ， 可以 用下面 的查询 命令： 



$ git log — pretty="%h - %s" — author=gitster — since="2008-10-01" \ 

— before="2008-1 1-01" —no-merges ― t/ 
5610e3b - Fix testcase failure when extended attribute 
acd3b9e - Enhance hold — lock— file— for— {update, append} ( ) 
f563754 - demonstrate breakage of detached checkout wi 
d1a43f2 - reset ― hard/ read-tree ― reset - u: remove un 
51a94af - Fix "checkout ― track 一 b newbranch" on detac 
bOadl 1e - pull: allow "git pull origin $something:$cur 

Git 项目有 20,000 多条 提交， 但我 们给出 搜索选 项后， 仅列 出了其 中满足 条件的 6 条。 

2.3.2 使 用图形 化工具 查阅提 交历史 

有时候 图形化 工具更 容易展 示历史 提交的 变化， 随 Git —同 发布的 gitk 就 是这样 一种工 
具。 它是用 Tcl/Tk 写 成的， 基本上 相当于 git log 命令的 可视化 版本， 凡是 git log 可以用 
的选 项也都 能用在 gitk 上。 在 项目工 作目录 中输入 gitk 命 令后， 就会 启动图 2-2 所 示的界 

面。 

上半个 窗口显 示的是 历次提 交的分 支祖先 图谱， 下半个 窗口显 示当前 点选的 提交对 应的具 
体 差异。 

2.4 撤 消操作 

任何 时候， 你 都有可 能需要 撤消刚 才所做 的某些 操作。 接 下来， 我们 会介绍 一些基 本的撤 
消操作 相关的 命令。 请 注意， 有些撤 销操作 是不可 逆的， 所 以请务 必谨慎 小心， 一旦 失误， 
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2.4 节 撤 消操作 



图 2.2: gitk 的图 形界面 

就 有可能 丢失部 分工作 成果。 

2.4.1 修改 最后一 次提交 

有时 候我们 提交完 了才发 现漏掉 了几个 文件没 有加， 或 者提交 信息写 错了。 想要撤 消刚才 

的提交 操作， 可 以使用 --amend 选 项重新 提交： 
$ git commit ― amend 

此命令 将使用 当前的 暂存区 域快照 提交。 如果刚 才提交 完没有 作任何 改动， 直接运 行此命 
令 的活， 相当于 有机会 重新编 辑提交 说明， 但将 要提交 的文件 快照和 之前的 一样。 

启动文 本编辑 器后， 会看到 上次提 交时的 说明， 编辑 它确认 没问题 后保存 退出， 就 会使用 
新 的提交 说明覆 盖刚才 失误的 提交。 

如 果刚才 提交时 忘了暂 存某些 修改， 可 以先补 上暂存 操作， 然后 再运行 一amend 提交： 

$ git commit -m 'initial commit' 
$ git add forgotten— file 
$ git commit ― amend 

上面的 三条命 令最终 只是产 生一个 提交， 第 二个提 交命令 修正了 第一个 的提交 内容。 

2.4.2 取消已 经暂存 的文件 

接下来 的两个 小节将 演示如 何取消 暂存区 域中的 文件， 以及如 何取消 工作目 录中已 修改的 
文件。 不用 担心， 查 看文件 状态的 时候就 提示了 该如何 撤消， 所 以不需 要死记 硬背。 来看下 

面的 例子， 有 两个修 改过的 文件， 我们想 要分开 提交， 但不 小心用 git add. 全 加到了 暂存区 
域。 该 如何撤 消暂存 其中的 一个文 件呢？ 其实， git status 的命令 输出已 经告诉 了我们 该怎么 

做： 
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$ git add . 




$ git status 




# On branch master 




# Changes to be committed: 




# (use "git reset HEAD <file>..." to u 


nstage) 


# 




# modified: README.txt 




# modified: benchmarks. rb 




# 





就在 "Changes to be committed" 下面， 括号 中有提 示， 可以 使用 git reset HEAD 
<file>... 的方 式取消 暂存。 好吧， 我们来 试试取 消暂存 benchnwks.rb 文件： 



$ git reset HEAD benchmarks. rb 
benchmarks. rb: locally modified 
$ git status 

# On branch master 

# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 
# 

# modified: README.txt 

# 

# Changes not staged for commit: 

# (use "git add <file>..." to update what will be committed ) 

# (use "git checkout 一一 <file>..." to discard changes in working directory) 

# 

# modified: benchmarks. rb 

# 



这条命 令看起 来有些 古怪， 先 别管， 能用 就行。 现在 benchmarks.rb 文件 又回到 了之前 
已 修改未 暂存的 状态。 

2.4.3 取消 对文件 的修改 

如 果觉得 刚才对 benchmarks.rb 的 修改完 全没有 必要， 该如 何取消 修改， 回到之 前的状 
态 （也就 是修改 之前的 版本） 呢？ git status 同 样提示 了具体 的撤消 方法， 接着 上面的 例子， 
现在 未暂存 区域看 起来像 这样： 

# Changes not staged for commit: 

# (use "git add <file>..." to update what will be committed ) 

# (use "git checkout 一一 <file>..." to discard changes in working directory) 
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# 

# modified: benchmarks. rb 

# 



在第 二个括 号中， 我们 看到了 抛弃文 件修改 的命令 （至 少在 Git 1.6.1 以及 更高版 本中会 
这样 提示， 如 果你还 在用老 版本， 我 们强烈 建议你 升级， 以 获取最 佳的用 户体验 ） ， 让我们 
试 试看： 



$ git checkout ― benchmarks. rb 




$ git status 




# On branch master 




# Changes to be committed: 




# (use "git reset HEAD <file>..." to u 


nstage) 


# 




# modified: README.txt 




# 





可以 看到， 该文件 已经恢 复到修 改前的 版本。 你 可能已 经意识 到了， 这条命 令有些 危险， 
所 有对文 件的修 改都没 有了， 因 为我们 刚刚把 之前版 本的文 件复制 过来重 写了此 文件。 所以 
在用 这条命 令前， 请 务必确 定真的 不再需 要保留 刚才的 修改。 如 果只是 想回退 版本， 同时保 

留刚才 的修改 以便将 来继续 工作， 可以 用下章 介绍的 stashing 和 分支来 处理， 应该 会更好 

些。 

记住， 任 何已经 提交到 Git 的都 可以被 恢复。 即便在 已经删 除的分 支中的 提交， 或者用 
-amend 重新 改写的 提交， 都可以 被恢复 （关于 数据恢 复的内 容见第 九章） 。 所以， 你可能 
失去的 数据， 仅 限于没 有提交 过的， 对 Git 来说 它们就 像从未 存在过 一样。 

2.5 远 程仓库 的使用 

要 参与任 何一个 Git 项目的 协作， 必须要 了解该 如何管 理远程 仓库。 远程仓 库是指 托管在 
网络上 的项目 仓库， 可能 会有好 多个， 其中有 些你只 能读， 另外 有些可 以写。 同他人 协作开 
发 某个项 目时， 需要 管理这 些远程 仓库， 以 便推送 或拉取 数据， 分 享各自 的工作 进展。 管理 
远程 仓库的 工作， 包括 添加远 程库， 移除废 弃的远 程库， 管 理各式 远程库 分支， 定义 是否跟 
踪这些 分支， 等等。 本 节我们 将详细 讨论远 程库的 管理和 使用。 

2.5.1 查看 当前的 远程库 

要查看 当前配 置有哪 些远程 仓库， 可以用 git remote 命令， 它 会列出 每个远 程库的 简短名 
字。 在 克隆完 某个项 目后， 至 少可以 看到一 个名为 origin 的远 程库， Git 默认 使用这 个名字 
来 标识你 所克隆 的原始 仓库： 

$ git clone git://g ithub.com/schacon/ticgit.git 

Initialized empty Git repository in /private/tmp/ticgit/.git/ 
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remote: Counting objects: 595, done. 

remote: Compressing objects: 100% (269/269), done. 

remote: Total 595 (delta 255), reused 589 (delta 253) 

Receiving objects: 100% (595/595), 73.31 KiB I 1 KiB/s, done. 

Resolving deltas: 100% (255/255), done. 

$ cd ticgit 

$ git remote 

origin 



也可 以加上 -v 选项 （ 译注： 此为 一verbose 的 简写， 取 首字母 ） ， 显 示对应 的克隆 地址: 



$ git remote -v 

origin git://g ithub.com/schacon/ticg it. git 




如 果有多 个远程 仓库， 此命令 将全部 列出。 比如 在我的 Grit 项 目中， 可以 看到： 

$ cd grit 

$ git remote -v 

bakkdoor git://g ithub.com/bakkdoor/grit.git 
cho45 git://g ithub.com/cho45/grit.git 
defunkt git://g ithub.com/defunkt/grit.git 
koke git://github.com/koke/grit.git 
origin git@github.com:mojom bo/grit. git 

这样 一来， 我 就可以 非常轻 松地从 这些用 户的仓 库中， 拉取 他们的 提交到 本地。 请 注意， 

上面列 出的地 址只有 origin 用的是 SSH URL 链接， 所 以也只 有这个 仓库我 能推送 数据上 
去 （ 我们 会在第 四章解 释原因 ） 。 

2.5.2 添加远 程仓库 

要添加 一个新 的远程 仓库， 可以指 定一个 简单的 名字， 以 便将来 引用， 运行 git remote add 
[shortname] [url]: 

$ git remote 
origin 

$ git remote add pb git://g ithub.com/paulboone/ticgit.git 
$ git remote -v 

origin git://g ithub.com/schacon/ticg it. git 
pb git://g ithub.com/paulboone/ticg it. git 
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现在 可以用 字符串 pb 指代 对应的 仓库地 址了。 比 如说， 要抓 取所有 Paul 有的， 但本地 
仓库 没有的 信息， 可 以运行 git fetch pb: 

$ git fetch pb 

remote: Counting objects: 58, done, 
remote: Compressing objects: 100% (41/41)， done, 
remote: Total 44 (delta 24), reused 1 (delta 0) 
Unpacking objects: 100% (44/44)， done. 
From git://github.com/paulboone/ticgit 
* [new branch] master -> pb/ master 



[new branch] ticgit -> pb/ticgit 




现在， Paul 的主 干分支 （master) 已 经完全 可以在 本地访 问了， 对应的 名字是 pb/ 
master, 你 可以将 它合并 到自己 的某个 分支， 或 者切换 到这个 分支， 看 看有些 什么有 趣的更 

新。 

2.5.3 从远程 仓库抓 取数据 

正如之 前所看 到的， 可以用 下面的 命令从 远程仓 库抓取 数据到 本地： 



$ git fetch [remote-name] 



此命令 会到远 程仓库 中拉取 所有你 本地仓 库中还 没有的 数据。 运行完 成后， 你就可 以在本 
地访问 该远程 仓库中 的所有 分支， 将 其中某 个分支 合并到 本地， 或者 只是取 出某个 分支， 一 
探 究竟。 （我 们会在 第三章 详细讨 论关于 分支的 概念和 操作。 ） 

如果 是克隆 了一个 仓库， 此 命令会 自动将 远程仓 库归于 origin 名下。 所以， git fetch origin 
会抓取 从你上 次克隆 以来别 人上传 到此远 程仓库 中的所 有更新 （或 是上次 fetch 以来 别人提 
交 的更新 ） 。 有 一点很 重要， 需要 记住， fetch 命令 只是将 远端的 数据拉 到本地 仓库， 并不 
自动合 并到当 前工作 分支， 只有 当你确 实准备 好了， 才 能手工 合并。 

如 果设置 了某个 分支用 于跟踪 某个远 端仓库 的分支 （参 见下 节及第 三章的 内容） ， 可以 
使用 git pull 命令 自动抓 取数据 下来， 然 后将远 端分支 自动合 并到本 地仓库 中当前 分支。 在 
日 常工作 中我们 经常这 么用， 既快 且好。 实 际上， 默认 情况下 git done 命令 本质上 就是自 
动 创建了 本地的 master 分支用 于跟踪 远程仓 库中的 master 分支 （假 设远 程仓库 确实有 
master 分支） 。 所以 一般我 们运行 git pull, 目的 都是要 从原始 克隆的 远端仓 库中抓 取数据 
后， 合并 到工作 目录中 的当前 分支。 

2.5.4 推送数 据到远 程仓库 

项 目进行 到一个 阶段， 要同别 人分享 目前的 成果， 可 以将本 地仓库 中的数 据推送 到远程 

仓库。 实 现这个 任务的 命令很 简单： git push [remote-name] [branch-nameL 如 果要把 本地的 
master 分支 推送到 origin 服 务器上 （再 次说 明下， 克隆操 作会自 动使用 默认的 master 和 
origin 名字 ）， 可 以运行 下面的 命令： 
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$ git push origin master 



只 有在所 克隆的 服务器 上有写 权限， 或 者同一 时刻没 有其他 人在推 数据， 这 条命令 才会如 
期完成 任务。 如果在 你推数 据前， 已经 有其他 人推送 了若干 更新， 那你 的推送 操作就 会被驳 
回。 你 必须先 把他们 的更新 抓取到 本地， 合 并到自 己的项 目中， 然 后才可 以再次 推送。 有关 
推 送数据 到远程 仓库的 详细内 容见第 三章。 

2.5.5 查看 远程仓 库信息 

我们 可以通 过命令 git remote show [remote-name] 查看 某个远 程仓库 的详细 信息， 比如要 
看所 克隆的 origin 仓库， 可以 运行： 

$ git remote show origin 
* remote origin 
URL: git://github.com/schacon/ticgit.git 

Remote branch merged with 'git pull' while on branch master 

master 
Tracked remote branches 

master 

ticgit 



除了 对应的 克隆地 址外， 它 还给出 了许多 额外的 信息。 它友 善地告 诉你如 果是在 master 
分支， 就 可以用 git pull 命令抓 取数据 合并到 本地。 另外 还列出 了所有 处于跟 踪状态 中的远 
端 分支。 

上 面的例 子非常 简单， 而随 着使用 Git 的 深入， git remote show 给 出的信 息可能 会像这 
样： 

$ git remote show origin 
* remote origin 
URL: git@github.com:defunkt/github.git 

Remote branch merged with 'git pull' while on branch issues 
issues 

Remote branch merged with 'git pull' while on branch master 
master 

New remote branches ( next fetch will store in remotes/origin) 
caching 

Stale tracking branches (use 'git remote prune') 

libwalker 

walker2 
Tracked remote branches 

acl 



36 



Scott Chacon Pro Git 



2.6 节 打标签 



apiv2 

dashboard2 
issues 
master 
postgres 

Local branch pushed with 'git push 
master:master 



它告诉 我们， 运行 git push 时缺 省推送 的分支 是什么 （ 译注： 最 后两行 ） 。 它还显 示了有 

哪些 远端分 支还没 有同步 到本地 （译注 ： 第 六行的 caching 分支 ） ， 哪 些已同 步到本 地的远 
端分 支在远 端服务 器上已 被删除 （ 译注： Stale tracking branches 下 面的两 个分支 ） ， 以及运 
行 git pull 时 将自动 合并哪 些分支 （ 译注： 前 四行中 列出的 issues 和 master 分支 ） 。 

2.5.6 远程 仓库的 删除和 重命名 

在新版 Git 中 可以用 git remote rename 命令 修改某 个远程 仓库在 本地的 简称， 比 如想把 
pb 改成 paul, 可 以这么 运行： 

$ git remote rename pb paul 

$ git remote 

origin 

paul 



注意， 对 远程仓 库的重 命名， 也会使 对应的 分支名 称发生 变化， 原来的 Pb/master 分支现 
在成了 paul/master 0 

碰到远 端仓库 服务器 迁移， 或者 原来的 克隆镜 像不再 使用， 又 或者某 个参与 者不再 贡献代 

码， 那么 需要移 除对应 的远端 仓库， 可 以运行 git remote rm 命令： 

$ git remote rm paul 
$ git remote 
origin 



2.6 打标签 

同 大多数 VCS —样， Git 也可以 对某一 时间点 上的版 本打上 标签。 人们在 发布某 个软件 
版本 （比如 v1.0 等等） 的 时候， 经常这 么做。 本 节我们 一起来 学习如 何列出 所有可 用的标 
签， 如 何新建 标签， 以 及各种 不同类 型标签 之间的 差别。 

2.6.1 列 显已有 的标签 

列出 现有标 签的命 令非常 简单， 直 接运行 git tag 即可： 
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$ git tag 

v0.1 

v1.3 



显 示的标 签按字 母顺序 排列， 所 以标签 的先后 并不表 示重要 程度的 轻重。 
我 们可以 用特定 的搜索 模式列 出符合 条件的 标签。 在 Git 自身 项目仓 库中， 有 着超过 240 
个 标签， 如果 你只对 1.4.2 系列的 版本感 兴趣， 可 以运行 下面的 命令： 

$ git tag -I 'v1.4.2.*' 

vl.4.2.1 

vl.4.2.2 

vl.4.2.3 

V1.4.2.4 



2.6.2 新 建标签 

Git 使用 的标签 有两种 类型： 轻 量级的 （lightweight) 和含 附注的 （annotated) 。 轻量 
级标签 就像是 个不会 变化的 分支， 实 际上它 就是个 指向特 定提交 对象的 引用。 而含 附注标 
签， 实际上 是存储 在仓库 中的一 个独立 对象， 它有 自身的 校验和 信息， 包含着 标签的 名字， 
电 子邮件 地址和 日期， 以 及标签 说明， 标签本 身也允 许使用 GNU Privacy Guard (GPG) 
来 签署或 验证。 一般 我们都 建议使 用含附 注型的 标签， 以便保 留相关 信息； 当然， 如 果只是 
临时 性加注 标签， 或者不 需要旁 注额外 信息， 用轻 量级标 签也没 问题。 

2.6.3 含附注 的标签 

创建 一个含 附注类 型的标 签非常 简单， 用 -a ( 译注： 取 annotated 的 首字母 ） 指 定标签 
名字 即可： 

$ git tag -a v1.4 -m 'my version 1.4' 

$ git tag 

v0.1 

v1.3 

v1.4 



而- m 选项 则指定 了对应 的标签 说明， Git 会 将此说 明一同 保存在 标签对 象中。 如 果没有 
给出该 选项， Git 会启动 文本编 辑软件 供你输 入标签 说明。 
可 以使用 git show 命令 查看相 应标签 的版本 信息， 并连同 显示打 标签时 的提交 对象。 

$ git show v1.4 
tag vl.4 
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Tagger: Scott Chacon <schacon@gee-mail.com> 
Date: Mon Feb 9 14:45:11 2009 -0800 

my version 1.4 

commit 15027957951 b64cf874c3557a0f3547bd83b3ff6 
Merge: 4a447f7... a6b4c97... 

Author: Scott Chacon <schacon@gee-mail.com> 
Date: Sun Feb 8 19:02:46 2009 -0800 



Merge branch 'experiment' 




我 们可以 看到在 提交对 象信息 上面， 列 出了此 标签的 提交者 和提交 时间， 以 及相应 的标签 
说明。 

2.6.4 签 署标签 

如 果你有 自己的 私钥， 还 可以用 GPG 来签署 标签， 只 需要把 之前的 -a 改为 -s (译注 ： 
取 signed 的首 字母） 即可： 

$ git tag - s v1.5 - m 'my signed 1.5 tag' 
You need a passphrase to unlock the secret key for 
user: "Scott Chacon <schacon@gee-mail.com>" 
1024-bit DSA key, ID F721C45A, created 2009-02-09 

现在 再运行 git show 会看到 对应的 GPG 签名 也附在 其内： 

$ git show v1.5 
tag vl.5 

Tagger: Scott Chacon <schacon@gee-mail.com> 
Date: Mon Feb 9 15:22:20 2009 -0800 

my signed 1.5 tag 

BEGIN PGP SIGNATURE 

Version: GnuPG v1.4.8 ( Darwin) 

iEYEABECAAYFAkmQurlACgl<QON3DxfchxFr5cACelMN+ZxLKggJQfOQYiQBwgySN 

KiOAn2JeAVUCAiJ70x6ZEtK+NvZAj82/ 

=WryJ 

END PGP SIGNATURE 

commit 15027957951 b64cf874c3557a0f3547bd83b3ff6 
Merge: 4a447f7... a6b4c97... 

Author: Scott Chacon <schacon@gee-mail.com> 
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Date: Sun Feb 8 19:02:46 2009 -0800 
Merge branch 'experiment' 



稍 后我们 再学习 如何验 证已经 签署的 标签。 

2.6.5 轻量 级标签 

轻 量级标 签实际 上就是 一个保 存着对 应提交 对象的 校验和 信息的 文件。 要 创建这 样的标 

签， 一个 -a, -s 或- m 选项都 不用， 直接 给出标 签名字 即可： 

$ git tag v1.4-lw 

$ git tag 

v0.1 

v1.3 

v1.4 



v1.4-lw 
v1.5 




现 在运行 git show 查看 此标签 信息， 就 只有相 应的提 交对象 摘要: 
$ git show v1.4-lw 

commit 15027957951 b64cf874c3557a0f3547bd83b3ff6 
Merge: 4a447f7... a6b4c97... 

Author: Scott Chacon <schacon@gee-mail.com> 
Date: Sun Feb 8 19:02:46 2009 -0800 



Merge branch 'experiment' 




2.6.6 验 证标签 

可 以使用 git tag -v [tag-name] ( 译注： 取 verify 的 首字母 ） 的 方式验 证已经 签署的 标签。 
此命令 会调用 GPG 来验证 签名， 所 以你需 要有签 署者的 公钥， 存放在 keyring 中， 才能验 
证： 

$ git tag -v v1.4.2.1 

object 883653babd8ee7ea23e6a5c392bb739348b1eb61 
type commit 
tag vl.4.2.1 

tagger Junio C Hamano <junkio@cox.net> 1158138501 -0700 
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GIT 1.4.2.1 

Minor fixes since 1.4.2, including git-mv and git-http with alternates. 

gpg: Signature made Wed Sep 13 02:08:25 2006 PDT using DSA key ID F3119B9A 

gpg: Good signature from "Junio C Hamano <junkio@cox.net>" 

gpg: aka "[jpeg image of size 1513]" 

Primary key fingerprint: 3565 2A26 2040 E066 C9A7 4A7D C0C6 D9A4 F311 9B9A 



若是 没有签 署者的 公钥， 会 报告类 似下面 这样的 错误： 

gpg: Signature made Wed Sep 13 02:08:25 2006 PDT using DSA key ID F3119B9A 
gpg: Can't check signature: public key not found 
error: could not verify the tag 'vl.4.2.1' 



2.6.7 后期加 注标签 

你甚至 可以在 后期对 早先的 某次提 交加注 标签。 比如 在下面 展示的 提交历 史中: 

$ git log ― pretty=oneline 

15027957951 b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment' 
a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support 
0d52aaab4479697da7686c15f77a3d64d9165190 one more thing 
6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiment' 
0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc added a commit function 
4682c3261057305bdd616e23b64b0857d832627b added a todo file 
166ae0c4d3f420721acbb115cc33848dfcc2121a started write support 
9fceb02d0ae598e95dc970b74767f19372d61af8 updated rakefile 
964f16d36dfccde844893cac5b347e7b3d44abbc commit the todo 
8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme 



我 们忘了 在提交 "updated rakefile" 后 为此项 目打上 版本号 v1.2， 没 关系， 现 在也能 
做。 只要在 打标签 的时候 跟上对 应提交 对象的 校验和 （ 或前几 位字符 ） 即可： 

$ git tag - a vl.2 9fceb02 



可以 看到我 们已经 补上了 标签： 
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$ git tag 

v0.1 

v1.2 

v1.3 

v1.4 

v1.4-lw 

v1.5 

$ git show v1.2 
tag v1.2 

Tagger: Scott Chacon <schacon@gee-mail.com> 
Date: Mon Feb 9 15:32:16 2009 -0800 

version 1.2 

commit 9fceb02d0ae598e95dc970b74767f19372d61af8 
Author: Magnus Chacon <mchacon@gee-mail.com> 
Date: Sun Apr 27 20:43:35 2008 -0700 

updated rakefile 




2.6.8 分 享标签 

默认情 况下， git push 并 不会把 标签传 送到远 端服务 器上， 只 有通过 显式命 令才能 分享标 

签 到远端 仓库。 其命令 格式如 同推送 分支， 运行 git push origin [tagname] 即可： 

$ git push origin v1.5 

Counting objects: 50, done. 

Compressing objects: 100% (38/38)， done. 

Writing objects: 100% (44/44)， 4.56 KiB, done. 

Total 44 (delta 18), reused 8 (delta 1) 

To git@github.com:schacon/simplegit.git 

* [new tag] v1.5 -> vl.5 



如 果要一 次推送 所有本 地新增 的标签 上去， 可 以使用 一tags 选项: 

$ git push origin ― tags 

Counting objects: 50, done. 

Compressing objects: 100% (38/38)， done. 

Writing objects: 100% (44/44)， 4.56 KiB, done. 

Total 44 {delta 18), reused 8 (delta 1) 
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To git@github.com:schacon/simplegit.git 





[new 


tag] 


vO.1 -> v0.1 




[new 


tag] 


v1.2 -> v1.2 




[new 


tag] 


v1.4 -> v1.4 




[new 


tag] 


v1.4-lw -> v1.4-lw 




[new 


tag] 


v1.5 -> v1.5 



现在， 其他人 克隆共 享仓库 或拉取 数据同 步后， 也会看 到这些 标签。 

2.7 技巧 和窍门 

在结 束本章 之前， 我 还想和 大家分 享一些 Git 使用的 技巧和 窍门。 很 多使用 Git 的 开发者 
可 能根本 就没用 过这些 技巧， 我 们也不 是说在 读过本 书后非 得用这 些技巧 不可， 但至 少应该 
有所了 解吧。 说 实活， 有了 这些小 窍门， 我 们的工 作可以 变得更 简单， 更 轻松， 更 高效。 

2.7.1 自 动补全 

如果你 用的是 Bash shell, 可以 试试看 Git 提 供的自 动补全 脚本。 下载 Git 的源 代码， 
进入 contrib/completion 目录， 会看到 一个 git-completion.bash 文件。 将 此文件 复制到 你自己 
的 用户主 目录中 （译注 ： 按照 下面的 示例， 还应 改名加 上点： cp git-completion.bash ~/.git- 
completion.bash ) , 并 把下面 一行内 容添加 到你的 .bashrx 文 件中： 



source ~/.g it-completion. bash 

也 可以为 系统上 所有用 户都设 置默认 使用此 脚本。 Mac 上将 此脚本 复制到 /opt/local/etc/ 
bash_completion.d 目 录中， Linux 上贝 lj 复制至 lj /etc/bash— completion.d/ 目 录中。 这两 处目录 
中的 脚本， 都会在 Bash 启动 时自动 加载。 

如果在 Windows 上 安装了 msysGit, 默认 使用的 Git Bash 就已经 配好了 这个自 动补全 
脚本， 可 以直接 使用。 

在输入 Git 命 令的时 候可以 敲两次 跳格键 （ Tab ) , 就 会看到 列出所 有匹配 的可用 命令建 
议： 

$ git co<tab><tab> 
commit config 



此 例中， 键入 git co 然后连 按两次 Tab 键， 会 看到两 个相关 的建议 （ 命令 ） commit 和 
config 。 继 而输入 m<tab> 会自 动完成 git commit 命令的 输入。 

命令的 选项也 可以用 这种方 式自动 完成， 其实 这种情 况更实 用些。 比 如运行 git log 的时 
候忘 了相关 选项的 名字， 可以输 入开头 的几个 字母， 然后敲 Tab 键 看看有 哪些匹 配的： 



43 



第 2 章 Git 基础 



Scott Chacon Pro Git 



$ git log — s<tab> 

-- shortstat ― since= -- src-prefix= -- stat ― summary 



这个 技巧不 错吧， 可 以节省 很多输 入和查 阅文档 的时间 。 

2.7.2 Git 命 令别名 

Git 并不会 推断你 输入的 几个字 符将会 是哪条 命令， 不过 如果想 偷懒， 少敲 几个命 令的字 
符， 可以用 gitconfig 为命 令设置 别名。 来看看 下面的 例子： 

$ git config ― global alias. co checkout 
$ git config ― global alias.br branch 
$ git config ― global alias. ci commit 
$ git config ― global alias. st status 



现在， 如果 要输入 git commit 只 需键入 git ci 即可。 而随着 Git 使用的 深入， 会有 很多经 
常要 用到的 命令， 遇 到这种 情况， 不妨 建个别 名提高 效率。 

使用 这种技 术还可 以创造 出新的 命令， 比方说 取消暂 存文件 时的输 入比较 繁琐， 可 以自己 
设置 一下： 

$ git config ― global alias. unstage 'reset HEAD ― ' 

这样 一来， 下面的 两条命 令完全 等同： 

$ git unstage fileA 
$ git reset HEAD fileA 



显然， 使用 别名的 方式看 起来更 清楚。 另外， 我 们还经 常设置 last 命令: 
$ git config ― global alias. last 'log -1 HEAD' 



然后 要看最 后一次 的提交 信息， 就变 得简单 多了: 
$ git last 

commit 66938dae3329c7aebe598c2246a8e6af90d04646 
Author: Josh Goebel <dreamer3@example.com> 
Date: Tue Aug 26 19:48:51 2008 +0800 



44 



Scott Chacon Pro Git 



2.8 节 小结 



test for current head 



Signed- off— by: Scott Chacon <schacon@example.com> 



可以 看出， 实际上 Git 只 是简单 地在命 令中替 换了你 设置的 别名。 不 过有时 候我们 希望运 
行某 个外部 命令， 而非 Git 的子 命令， 这个 好办， 只 需要在 命令前 加上！ 就行。 如果 你自己 
写了 些处理 Git 仓 库信息 的脚本 的活， 就 可以用 这种技 术包装 起来。 作为 演示， 我们 可以设 

置用 git visual 启动 gitk: 



$ git config ― global alias. visual '！ gitk' 



2.8 小结 

到目前 为止， 你 已经学 会了最 基本的 Git 本地 操作： 创建 和克隆 仓库， 做出 修改， 暂存并 
提 交这些 修改， 以 及查看 所有历 史修改 记录。 接 下来， 我们 将学习 Git 的 必杀技 特性： 分支 
模型。 
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几 乎每一 种版本 控制系 统都以 某种形 式支持 分支。 使用 分支意 味着你 可以从 开发主 线上分 
离 开来， 然 后在不 影晌主 线的同 时继续 工作。 在很 多版本 控制系 统中， 这是个 昂贵的 过程， 
常 常需要 创建一 个源代 码目录 的完整 副本， 对大型 项目来 说会花 费很长 时间。 

有人把 Git 的 分支模 型称为 "必 杀技 特性" ， 而 正是因 为它， 将 Git 从版本 控制系 统家族 
里区分 出来。 Git 有何 特别之 处呢？ Git 的分支 可谓是 难以置 信的轻 量级， 它 的新建 操作几 
乎可以 在瞬间 完成， 并且 在不同 分支间 切换起 来也差 不多一 样快。 和许 多其他 版本控 制系统 
不同， Git 鼓励在 工作流 程中频 繁使用 分支与 合并， 哪怕 一天之 内进行 许多次 都没有 关系。 
理解 分支的 概念并 熟练运 用后， 你才会 意识到 为什么 Git 是一 个如此 强大而 独特的 工具， 并 
从 此真正 改变你 的开发 方式。 

3.1 何 谓分支 

为 了理解 Git 分支 的实现 方式， 我们 需要回 顾一下 Git 是如何 储存数 据的。 或许你 还记得 
第 一章的 内容， Git 保存的 不是文 件差异 或者变 化量， 而只 是一系 列文件 快照。 

在 Git 中提 交时， 会 保存一 个提交 （commit) 对象， 该对象 包含一 个指向 暂存内 容快照 
的 指针， 包含 本次提 交的作 者等相 关附属 信息， 包 含零个 或多个 指向该 提交对 象的父 对象指 
针： 首 次提交 是没有 直接祖 先的， 普 通提交 有一个 祖先， 由两个 或多个 分支合 并产生 的提交 
则 有多个 祖先。 

为直观 起见， 我 们假设 在工作 目录中 有三个 文件， 准备 将它们 暂存后 提交。 暂存操 作会对 
每 一个文 件计算 校验和 （ 即第 一章中 提到的 SHA-1 哈 希字串 ） ， 然后 把当前 版本的 文件快 
照 保存到 Git 仓库中 （ Git 使用 blob 类型 的对象 存储这 些快照 ） ， 并 将校验 和加入 暂存区 
域： 

$ git add README test.rb LICENSE 

$ git commit -m 'initial commit of my project' 



当使用 git commit 新 建一个 提交对 象前， Git 会 先计算 每一个 子目录 （ 本例 中就是 项目根 
目录 ） 的校 验和， 然后在 Git 仓库中 将这些 目录保 存为树 （ tree ) 对象。 之后 Git 创 建的提 
交 对象， 除 了包含 相关提 交信息 以外， 还包 含着指 向这个 树对象 （项 目根 目录） 的 指针， 如 
此它 就可以 在将来 需要的 时候， 重现 此次快 照的内 容了。 

现在， Git 仓库中 有五个 对象： 三个 表示文 件快照 内容的 blob 对象； 一个 记录着 目录树 
内容 及其中 各个文 件对应 blob 对象 索引的 tree 对象； 以及 一个包 含指向 tree 对象 （ 根目 
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录 ） 的索 引和其 他提交 信息元 数据的 commit 对象。 
的 数据和 相互关 系看起 来如图 3-1 所示： 



概念上 来说， 仓 库中的 各个对 象保存 
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图 3.1: 单个提 交对象 在仓库 中的数 据结构 

作 些修改 后再次 提交， 那 么这次 的提交 对象会 包含一 个指向 上次提 交对象 的指针 （ 译注: 
即下 图中的 parent 对象 ） 。 两次提 交后， 仓库 历史会 变成图 3-2 的 样子： 
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图 3.2: 多 个提交 对象之 间的链 接关系 

现 在来谈 分支。 Git 中的 分支， 其实 本质上 仅仅是 个指向 commit 对象 的可变 指针。 Git 
会使用 master 作 为分支 的默认 名字。 在若 干次提 交后， 你其实 已经有 了一个 指向最 后一次 
提交 对象的 master 分支， 它在每 次提交 的时候 都会自 动向前 移动。 
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图 3.3: 分 支其实 就是从 某个提 交对象 往回看 的历史 



那么， Git 又是如 何创建 一个新 的分支 的呢？ 答案很 简单， 创建 一个新 的分支 指针。 比如 
新建一 个 testing 分支， 可 以使用 git branch 命令： 
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$ git branch testing 

这会 在当前 commit 对象上 新建一 个分 支指针 （ 见图 3-4 ) 。 



i 



98ca9 




34ac2 




f30ab 







图 3.4: 多 个分支 指向提 交数据 的历史 

那么， Git 是 如何知 道你当 前在哪 个分支 上工作 的呢？ 其实答 案也很 简单， 它保存 着一个 
名为 HEAD 的特别 指针。 请 注意它 和你熟 知的许 多其他 版本控 制系统 （比如 Subversion 
或 CVS ) 里的 HEAD 概 念大不 相同。 在 Git 中， 它是一 个指向 你正在 工作中 的本地 分支的 
指针 （译注 ： 将 HEAD 想象 为当前 分支的 别名。 ）。 运行 git branch 命令， 仅仅 是建立 了一 
个新的 分支， 但不会 自动切 换到这 个分支 中去， 所以在 这个例 子中， 我们依 然还在 master 
分支 里工作 （ 参考图 3-5 ) 。 



HEAD 
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f30ab 







testing 

图 3.5: HEAD 指向当 前所在 的分支 

要切换 到其他 分支， 可 以执行 git checkout 命令。 我 们现在 转换到 新建的 testing 分支: 

$ git checkout testing 

这样 HEAD 就 指向了 testing 分支 （ 见图 3- 6 ) 。 

这 样的实 现方式 会给我 们带来 什么好 处呢？ 好吧， 现 在不妨 再提交 一次： 
$ vim test.rb 

$ git commit -a 一 m 'made a change' 
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98ca9 







master 










34ac2 




f30ab 
















testing 














HEAD 



图 3.6: HEAD 在 你转换 分支时 指向新 的分支 
图 3-7 展 示了提 交后的 结果。 



98ca9 



34ac2 



f30ab 



c2b9e 



testir>g 




图 3.7: 每次 提交后 HEAD 随 着分支 一起向 前移动 

非常 有趣， 现在 testing 分 支向前 移动了 一格， 而 master 分支 仍然指 向原先 git checkout 
时 所在的 commit 对象。 现在我 们回到 master 分支 看看： 



$ git checkout master 



图 3-8 显示了 结果。 




98ca9 



34ac2 




£30ab 





c2b9e 



testing 



图 3.8: HEAD 在一次 checkout 之后 移动到 了另一 个分支 
这 条命令 做了两 件事。 它把 HEAD 指针 移回到 master 分支， 并把 工作目 录中的 文件换 
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成了 master 分支 所指向 的快照 内容。 也就 是说， 现 在开始 所做的 改动， 将始 于本项 目中一 
个 较老的 版本。 它的 主要作 用是将 testing 分 支里作 出的修 改暂时 取消， 这样 你就可 以向另 
一个方 向进行 开发。 
我们作 些修改 后再次 提交： 



$ vim test.rb 

$ git commit - a - m 'made other changes' 

现 在我们 的项目 提交历 史产生 了分叉 （ 如图 3-9 所示 ） ， 因为 刚才我 们创建 了一个 分支， 

转 换到其 中进行 了一些 工作， 然后又 回到原 来的主 分支进 行了另 外一些 工作。 这些改 变分别 
孤 立在不 同的分 支里： 我们可 以在不 同分支 里反复 切换， 并在 时机成 熟时把 它们合 并到一 

起。 而所 有这些 工作， 仅 仅需要 branch 和 checkout 这两 条命令 就可以 完成。 



HEAD 






master 









H 








98ca9 




34ac2 




£30ab 



c2b9e 



testing 



图 3.9: 不同流 向的分 支历史 

由于 Git 中的 分支实 际上仅 是一个 包含所 指对象 校验和 （ 40 个字 符长度 SHA-1 字串 ） 
的 文件， 所 以创建 和销毀 一个分 支就变 得非常 廉价。 说 白了， 新 建一个 分支就 是向一 个文件 
写入 41 个字节 （ 外 加一个 换行符 ） 那么 简单， 当然 也就很 快了。 

这 和大多 数版本 控制系 统形成 了鲜明 对比， 它 们管理 分支大 多采取 备份所 有项目 文件到 
特定 目录的 方式， 所 以根据 项目文 件数量 和大小 不同， 可能花 费的时 间也会 有相当 大的差 
另 U, 快则 几秒， 慢则数 分钟。 而 Git 的实现 与项目 复杂度 无关， 它永远 可以在 几毫秒 的时间 
内完成 分支的 创建和 切换。 同时， 因为每 次提交 时都记 录了祖 先信息 （译注 ： 即 parent 对 
象）， 将来要 合并分 支时， 寻找恰 当的合 并基础 （译注 ： 即共同 祖先） 的工作 其实已 经自然 
而然地 摆在那 里了， 所以 实现起 来非常 容易。 Git 鼓励开 发者频 繁使用 分支， 正是因 为有着 
这些 特性作 保障。 

接下来 看看， 我们 为什么 应该频 繁使用 分支。 

3.2 分支 的新建 与合并 

现在让 我们来 看一个 简单的 分支与 合并的 例子， 实际 工作中 大体也 会用到 这样的 工作流 
程： 

1. 开 发某个 网站。 
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2. 为 实现某 个新的 需求， 创 建一个 分支。 

3. 在这 个分支 上开展 工作。 

假设 此时， 你 突然接 到一个 电活说 有个很 严重的 问题需 要紧急 修补， 那么可 以按照 下面的 
方式 处理： 

1. 返回 到原先 已经发 布到生 产服务 器上的 分支。 

2. 为这次 紧急修 补建立 一个新 分支， 并在其 中修复 问题。 

3. 通过测 试后， 回 到生产 服务器 所在的 分支， 将 修补分 支合并 进来， 然后 再推送 到生产 
服务 器上。 

4. 切换 到之前 实现新 需求的 分支， 继续 工作。 

3.2.1 分支 的新建 与切换 

首先， 我 们假设 你正在 项目中 愉快地 工作， 并且 已经提 交了几 次更新 （见图 3-10) 。 



( CO ) "*~~ (""^"") ""~ ( C2 ) 

图 3.10: —个简 短的提 交历史 

现在， 你决 定要修 补问题 追踪系 统上的 #53 问题。 顺带说 明下， Git 并不同 任何特 定的问 
题追踪 系统打 交道。 这 里为了 说明要 解决的 问题， 才 把新建 的分支 取名为 iss53。 要 新建并 
切 换到该 分支， 运行 git checkout 并加上 -b 参数： 

$ git checkout - b iss53 
Switched to a new branch "iss53" 

这相 当于执 行下面 这两条 命令： 

$ git branch iss53 
$ git checkout iss53 

图 3-11 示意 该命令 的执行 结果。 



T 
I I 

图 3.11: 创建 了一个 新分支 的指针 
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接着你 开始尝 试修复 问题， 在提 交了若 干次更 新后， iss53 分支的 指针也 会随着 向前推 
进， 因为它 就是当 前分支 （换句 活说， 当前的 HEAD 指针 正指向 iss53, 见图 3-12) ： 

$ vim index.html 

$ git commit - a - m 'added a new footer [issue 53]' 



， 




图 3.12: iss53 分支 随工作 进展向 前推进 

现 在你就 接到了 那个网 站问题 的紧急 电话， 需 要马上 修补。 有了 Git , 我们 就不需 要同时 
发 布这个 补丁和 iss53 里 作出的 修改， 也不 需要在 创建和 发布该 补丁到 服务器 之前花 费大力 
气来复 原这些 修改。 唯一 需要的 仅仅是 切换回 master 分支。 

不 过在此 之前， 留心你 的暂存 区或者 工作目 录里， 那些 还没有 提交的 修改， 它会和 你即将 
检 出的分 支产生 冲突从 而阻止 Git 为 你切换 分支。 切换分 支的时 候最好 保持一 个清洁 的工作 
区域。 稍 后会介 绍几个 绕过这 种问题 的办法 （分 别叫做 stashing 和 commit amending) 。 
目 前已经 提交了 所有的 修改， 所以接 下来可 以正常 转换到 master 分支： 

$ git checkout master 
Switched to branch "master" 

此时 工作目 录中的 内容和 你在解 决问题 #53 之 前一模 一样， 你可以 集中精 力进行 紧急修 
补。 这一 点值得 牢记： Git 会 把工作 目录的 内容恢 复为检 出某分 支时它 所指向 的那个 提交对 
象的 快照。 它 会自动 添加、 删除和 修改文 件以确 保目录 的内容 和你当 时提交 时完全 一样。 

接 下来， 你得进 行紧急 修补。 我们创 建一个 紧急修 补分支 hotfix 来开展 工作， 直 到搞定 
(见图 3-13) ： 

$ git checkout -b 'hotfix' 
Switched to a new branch "hotfix" 
$ vim index.html 

$ git commit - a - m 'fixed the broken email address' 
[hotfix]: created 3a0874c: "fixed the broken email address" 
1 files changed, 0 insertions( + ), 1 deletions ( — ) 

有必 要作些 测试， 确保修 补是成 功的， 然 后回到 master 分 支并把 它合并 进来， 然 后发布 
到 生产服 务器。 用 git merge 命令 来进行 合并： 
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master I hotfix 



C3 



图 3.13: hotfix 分 支是从 master 分 支所在 点分化 出来的 



$ git checkout master 
$ git merge hotfix 
Updating f42c576..3a0874c 
Fast forward 
README I 1 - 

1 files changed, 0 insertions( + ), 1 deletions (-) 



请 注意， 合并时 出现了 "Fast forward" 的 提示。 由 于当前 master 分支所 在的提 交对象 
是要 并入的 hotfix 分支 的直接 上游， Git 只需把 master 分支指 针直接 右移。 换句 活说， 如果 
顺着一 个分支 走下去 可以到 达另一 个分支 的活， 那么 Git 在 合并两 者时， 只会 简单地 把指针 
右移， 因为这 种单线 的历史 分支不 存在任 何需要 解决的 分歧， 所 以这种 合并过 程可以 称为快 
进 ( Fast forward ) 。 

现在最 新的修 改已经 在当前 master 分 支所指 向的提 交对象 中了， 可 以部署 到生产 服务器 
上去了 （见图 3-14) 。 




图 3.14: 合并 之后， master 分支和 hotfix 分支指 向同一 位置。 

在那个 超级重 要的修 补发布 以后， 你想 要回到 被打扰 之前的 工作。 由 于当前 hotfix 分支 
和 master 都指 向相同 的提交 对象， 所以 hotfix 已 经完成 了历史 使命， 可以删 掉了。 使用 git 
branch 的 -d 选项执 行删除 操作： 



$ git branch - d hotfix 
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Deleted branch hotfix (3a0874c). 



现 在回到 之前未 完成的 #53 问题 修复分 支上继 续工作 （图 3-15 ) ： 



$ git checkout iss53 
Switched to branch "iss53" 
$ vim index.html 

$ git commit -a - m 'finished the new footer [issue 53]' 
[iss53]: created ad82d7a: "finished the new footer [issue 53]' 
1 files changed, 1 insertions( + ), 0 deletions (-) 




图 3.15: iss53 分 支可以 不受影 晌继续 推进。 

不用担 心之前 hotfix 分支的 修改内 容尚未 包含到 iss53 中来。 如果 确实需 要纳入 此次修 
补， 可以用 git merge master 把 master 分支 合并到 iss53; 或者等 iss53 完成 之后， 再将 
iss53 分支 中的更 新并入 master。 

3.2.2 分支 的合并 

在问题 #53 相 关的工 作完成 之后， 可以 合并回 master 分支。 实际操 作同前 面合并 hotfix 
分支差 不多， 只 需回到 master 分支， 运行 git merge 命 令指定 要合并 进来的 分支： 



$ git checkout master 
$ git merge iss53 
Merge made by recursive. 
README I 1 + 

1 files changed, 1 insertions( + ), 0 deletions (-) 



请 注意， 这次合 并操作 的底层 实现， 并不同 于之前 hotfix 的并入 方式。 因 为这次 你的开 
发 历史是 从更早 的地方 开始分 叉的。 由 于当前 master 分 支所指 向的提 交对象 （ C4 ) 并不是 
iss53 分支 的直接 祖先， Git 不得不 进行一 些额外 处理。 就此例 而言， Git 会用 两个分 支的末 
端 （ C4 和 C5 ) 以及它 们的共 同祖先 （ C2 ) 进行一 次简 单的三 方合并 计算。 图 3-16 用红 
框 标出了 Git 用于合 并的三 个提交 对象： 
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(Snapshot to 
Merge Into 




r Snapshot to 
\^ Merge In 



图 3.16: Git 为 分支合 并自动 识别出 最佳的 同源合 并点。 

这次， Git 没 有简单 地把分 支指针 右移， 而是对 三方合 并后的 结果重 新做一 个新的 快照， 
并自动 创建一 个指向 它的提 交对象 （C6) (见图 3-17) 。 这个 提交对 象比较 特殊， 它有两 
个祖先 （ C4 和 C5 ) 。 

值得一 提的是 Git 可以自 己裁决 哪个共 同祖先 才是最 佳合并 基础； 这和 CVS 或 Subver- 
sion ( 1.5 以后的 版本） 不同， 它 们需要 开发者 手工指 定合并 基础。 所以此 特性让 Git 的合 
并操作 比其他 系统都 要简单 不少。 




图 3.17: Git 自动 创建了 一个包 含了合 并结果 的提交 对象。 

既然 之前的 工作成 果已经 合并到 master 了， 那么 i SS 53 也就没 用了。 你可以 就此删 除它, 
并在问 题追踪 系统里 关闭该 问题。 



$ git branch - d iss53 



3.2.3 遇 到冲突 时的分 支合并 

有时候 合并操 作并不 会如此 顺利。 如果在 不同的 分支中 都修改 了同一 个文件 的同一 部分， 
Git 就 无法干 净地把 两者合 到一起 （译注 ： 逻辑 上说， 这种问 题只能 由人来 裁决。 ） 。 如果 
你在解 决问题 #53 的 过程中 修改了 hotfix 中 修改的 部分， 将得 到类似 下面的 结果： 
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$ git merge iss53 
Auto-merging index.html 

CONFLICT (content): Merge conflict in index.html 

Automatic merge failed; fix conflicts and then commit the result. 



Git 作了 合并， 但没有 提交， 它会停 下来等 你解决 冲突。 要看 看哪些 文件在 合并时 发生冲 
突， 可以用 git status 查阅： 

[master*]$ git status 
index.html: needs merge 

# On branch master 

# Changes not staged for commit: 

# (use "git add <file>..." to update what will be committed) 

# (use "git checkout 一一 <file>..." to discard changes in working directory) 
# 

# unmerged: index.html 
# 



任何包 含未解 决冲突 的文件 都会以 未合并 （unmerged) 的状态 列出。 Git 会在有 冲突的 

文件里 加入标 准的冲 突解决 标记， 可 以通过 它们来 手工定 位并解 决这些 冲突。 可以看 到此文 
件 包含类 似下面 这样的 部分： 

«««< HEAD:index.html 

<div id="footer">contact : email.support@github.com</div> 



<div id="footer"> 

please contact us at support@github.com 
</div> 

»>»» iss53:index.html 

可 以看到 ======= 隔开 的上半 部分， 是 HEAD ( 即 master 分支， 在运行 merge 命令 时所切 

换到的 分支） 中的 内容， 下半部 分是在 iss53 分 支中的 内容。 解 决冲突 的办法 无非是 二者选 
其一 或者由 你亲自 整合到 一起。 比如 你可以 通过把 这段内 容替换 为下面 这样来 解决： 

<div id="footer"> 

please contact us at email.support@github.com 
</div> 



这 个解决 方案各 采纳了 两个分 支中的 一部分 内容， 而且我 还删除 了 <<<<<<<， ======= 和 

》>〉>》这 些行。 在 解决了 所有文 件里的 所有冲 突后， 运行 git add 将把 它们标 记为已 解决状 
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态 （ 译注： 实际上 就是来 一次快 照保存 到暂存 区域。 ） 。 因 为一旦 暂存， 就表 示冲突 已经解 

决。 如果 你想用 一个有 图形界 面的工 具来解 决这些 问题， 不 妨运行 git mergetool, 它 会调用 
一个可 视化的 合并工 具并引 导你解 决所有 冲突： 

$ git mergetool 

merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff 
Merging the files: index.html 

Normal merge conflict for 'index.html': 

{local}: modified 

{remote}: modified 
Hit return to start merge resolution tool (opendiff): 



如果不 想用默 认的合 并工具 （ Git 为 我默认 选择了 opendiff, 因 为我在 Mac 上运行 了该命 
令）， 你可以 在上方 "merge tool candidates" 里 找到可 用的合 并工具 列表， 输入 你想用 
的工 具名。 我们将 在第七 章讨论 怎样改 变环境 中的默 认值。 

退出合 并工具 以后， Git 会询 问你合 并是否 成功。 如果回 答是， 它会 为你把 相关文 件暂存 
起来， 以 表明状 态为已 解决。 

再运 行一次 git status 来确认 所有冲 突都已 解决： 



$ git status 




# On branch master 




# Changes to be committed: 




# (use "git reset HEAD <file>..." to u 


nstage) 


# 




# modified: index.html 




# 







如果 觉得满 意了， 并 且确认 所有冲 突都已 解决， 也 就是进 入了暂 存区， 就 可以用 git 

commit 来 完成这 次合并 提交。 提交的 记录差 不多是 这样： 



Merge branch 'iss53' 

Conflicts: 
index.html 

# 

# It looks like you may be committing a MERGE. 

# If this is not correct, please remove the file 

# .git/MERGE — HEAD 

# and try again. 
# 
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如果想 给将来 看这次 合并的 人一些 方便， 可以 修改该 信息， 提供更 多合并 细节。 比 如你都 
作 了哪些 改动， 以及这 么做的 原因。 有时候 裁决冲 突的理 由并不 直接或 明显， 有必要 略加注 

解。 

3.3 分支 的管理 

到目前 为止， 你已 经学会 了如何 创建、 合并 和删除 分支。 除此 之外， 我们还 需要学 习如何 
管理 分支， 在日后 的常规 工作中 会经常 用到下 面介绍 的管理 命令。 

git branch 命令 不仅仅 能创建 和删除 分支， 如果不 加任何 参数， 它会 给出当 前所有 分支的 
清单： 

$ git branch 

iss53 
* master 

testing 



注意看 master 分 支前的 * 字符： 它表 示当前 所在的 分支。 也就 是说， 如 果现在 提交更 
新， master 分支将 随着开 发进度 前移。 若要 查看各 个分支 最后一 个提交 对象的 信息， 运行 

git branch - v: 

$ git branch -v 

iss53 93b412c fix javascript issue 
* master 7a98805 Merge branch 'iss53' 

testing 782fd34 add scott to the author list in the readmes 



要从该 清单中 筛选出 你已经 （ 或尚未 ） 与当 前分支 合并的 分支， 可以用 一merge 和 一no- 
merged 选项 （ Git 1.5.6 以 上版本 ） 。 比如用 git branch -merge 查看哪 些分支 已被并 入当前 
分支 （ 译注： 也 就是说 哪些分 支是当 前分支 的直接 上游。 ） ： 

$ git branch -- merged 

iss53 
* master 

之前我 们已经 合并了 iss53, 所 以在这 里会看 到它。 一般 来说， 列表 中没有 * 的分 支通常 
都 可以用 git branch -d 来 删掉。 原因很 简单， 既然 已经把 它们所 包含的 工作整 合到了 其他分 
支， 删 掉也不 会损失 什么。 

另外 可以用 git branch -no-merged 查 看尚未 合并的 工作： 

$ git branch -- no-merged 
testing 
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它会 显示还 未合并 进来的 分支。 由于 这些分 支中还 包含着 尚未合 并进来 的工作 成果， 所以 

简 单地用 git branch -d 删除 该分支 会提示 错误， 因为 那样做 会丢失 数据： 
$ git branch - d testing 

error: The branch 'testing' is not an ancestor of your current HEAD. 
If you are sure you want to delete it, run 'git branch -D testing'. 

不过， 如果 你确实 想要删 除该分 支上的 改动， 可 以用大 写的删 除选项 -D 强制 执行， 就像 
上 面提示 信息中 给出的 那样。 



3.4 利 用分支 进行开 发的工 作流程 

现 在我们 已经学 会了新 建分支 和合并 分支， 可以 （ 或应该 ） 用它来 做点什 么呢？ 在 本节， 
我们会 介绍一 些利用 分支进 行开发 的工作 流程。 而 正是由 于分支 管理的 便捷， 才衍生 出了这 
类典型 的工作 模式， 你可以 根据项 目 的 实际情 况选择 一种用 用看。 



3.4.1 长 期分支 

由于 Git 使 用简单 的三方 合并， 所 以就算 在较长 一段时 间内， 反复多 次把某 个分支 合并到 
另一 分支， 也不 是什么 难事。 也就 是说， 你可以 同时拥 有多个 开放的 分支， 每 个分支 用于完 
成 特定的 任务， 随着 开发的 推进， 你可 以随时 把某个 特性分 支的成 果并到 其他分 支中。 

许 多使用 Git 的开发 者都喜 欢用这 种方式 来开展 工作， 比 如仅在 master 分 支中保 留完全 
稳定的 代码， 即已 经发布 或即将 发布的 代码。 与此 同时， 他们 还有一 个名为 develop 或 next 
的平行 分支， 专 门用于 后续的 开发， 或仅用 于稳定 性测试 一 当然并 不是说 一定要 绝对稳 
定， 不 过一旦 进入某 种稳定 状态， 便可 以把它 合并到 master 里。 这样， 在确 保这些 已完成 
的特 性分支 （短期 分支， 比如 之前的 iss53 分支） 能够通 过所有 测试， 并且不 会引入 更多错 
误 之后， 就可 以并到 主干分 支中， 等待下 一次的 发布。 

本质 上我们 刚才谈 论的， 是随着 提交对 象不断 右移的 指针。 稳 定分支 的指针 总是在 提交历 
史中 落后一 大截， 而前 沿分支 总是比 较靠前 （见图 3-18) 。 




图 3.18: 稳定 分支总 是比较 老旧。 



或者 把它们 想象成 工作流 水线， 或许更 好理解 一些， 经 过测试 的提交 对象集 合被遴 选到更 
稳定的 流水线 （见图 3-19) 。 

你可 以用这 招维护 不同层 次的稳 定性。 某些大 项目还 会有个 proposed (建议 ） 或 P u ( proposed 
updates, 建议 更新） 分支， 它 包含着 那些可 能还没 有成熟 到进入 next 或 master 的 内容。 
这么做 的目的 是拥有 不同层 次的稳 定性： 当 这些分 支进入 到更稳 定的水 平时， 再把它 们合并 
到更高 层分支 中去。 再次说 明下， 使 用多个 长期分 支的做 法并非 必需， 不 过一般 来说， 对于 
特 大型项 目或特 复杂的 项目， 这么 做确实 更容易 管理。 
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图 3.19: 想 象成流 水线可 能会容 易点。 



3.4.2 特 性分支 

在 任何规 模的项 目中都 可以使 用特性 （Topic) 分支。 一个 特性分 支是指 一个短 期的， 用 
来实现 单一特 性或与 其相关 工作的 分支。 可 能你在 以前的 版本控 制系统 里从未 做过类 似这样 
的 事情， 因 为通常 创建与 合并分 支消耗 太大。 然而在 Git 中， 一 天之内 建立、 使用、 合并再 
删除多 个分支 是常见 的事。 

我 们在上 节的例 子里已 经见过 这种用 法了。 我们 创建了 iss53 和 hotfix 这两 个特性 分支， 
在 提交了 若干更 新后， 把它 们合并 到主干 分支， 然后 删除。 该技 术允许 你迅速 且完全 的进行 
语 境切换 一因为 你的工 作分散 在不同 的流水 线里， 每个 分支里 的改变 都和它 的目标 特性相 
关， 浏览代 码之类 的事情 因而变 得更简 单了。 你 可以把 作出的 改变保 持在特 性分支 中几分 
钟， 几天 甚至几 个月， 等它 们成熟 以后再 合并， 而不 用在乎 它们建 立的顺 序或者 进度。 

现在我 们来看 一个 实际的 例子。 请看图 3-20, 由下 往上， 起先 我们在 master 工作到 
C1, 然后开 始一个 新分支 iss91 尝 试修复 91 号 缺陷， 提交到 C6 的 时候， 又 冒出一 个解决 
该问 题的新 办法， 于是 从之前 C4 的地 方又 分出一 个分支 i SS 91v2, 干到 C8 的时 候， 又回到 
主干 master 中 提交了 C9 和 C10, 再回到 iss91v2 继续 工作， 提交 C11, 接着， 又冒 出个不 
太 确定的 想法， 从 master 的最 新提交 C10 处开 了个新 的分支 dumbidea 做些 试验。 




图 3.20: 拥有 多个特 性分支 的提交 历史。 



现在， 假 定两件 事情： 我 们最终 决定使 用第二 个解决 方案， 即 iss91v2 中的 办法； 另外， 
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我们把 dumbidea 分支拿 给同事 们看了 以后， 发现它 竟然是 个天才 之作。 所以接 下来， 我们 
准 备抛弃 原来的 分支 （ 实际上 会丢弃 C5 和 C6 ) , 直接在 主干中 并入另 外两个 分支。 
最终 的提交 历史将 变成图 3-21 这样： 




图 3.21: 合并了 dumbidea 和 iss91v2 后 的分支 历史。 

请务必 牢记这 些分支 全部都 是本地 分支， 这 一点很 重要。 当你 在使用 分支及 合并的 时候, 
一切都 是在你 自己的 Git 仓库中 进行的 一 完 全不涉 及与服 务器的 交互。 



3.5 远 程分支 

远 程分支 （ remote branch ) 是对 远程仓 库中的 分支的 索引。 它们是 一些无 法移动 的本地 
分支； 只有在 Git 进行网 络交互 时才会 更新。 远 程分支 就像是 书签， 提 醒着你 上次连 接远程 
仓库时 上面各 分支的 位置。 

我们用 （远程 仓库名 )/ (分 支名） 这样的 形式表 示远程 分支。 比 如我们 想看看 上次同 origin 仓 
库 通讯时 master 分支的 样子， 就应 该查看 origin/master 分支。 如果你 和同伴 一起修 复某个 
问题， 但他们 先推送 了一个 iss53 分支 到远程 仓库， 虽然你 可能也 有一个 本地的 iss53 分支， 
但 指向服 务器上 最新更 新的却 应该是 CKigin/issSS 分支。 

可能有 点乱， 我们不 妨举例 说明。 假设 你们团 队有个 地址为 git.ourcompany.com 的 Git 服 
务器。 如果你 从这里 克隆， Git 会自 动为你 将此远 程仓库 命名为 origin, 并下 载其中 所有的 
数据， 建立 一个指 向它的 master 分支的 指针， 在本地 命名为 origin/master, 但你无 法在本 
地 更改其 数据。 接着， Git 建立一 个属于 你自己 的本地 master 分支， 始于 origin 上 master 
分支 相同的 位置， 你可以 就此开 始工作 （见图 3-22) ： 

如果你 在本地 master 分支 做了些 改动， 与此 同时， 其 他人向 git.ourcompany.com 推 送了他 
们的 更新， 那 么服务 器上的 master 分支就 会向前 推进， 而于此 同时， 你在本 地的提 交历史 
正 朝向不 同方向 发展。 不 过只要 你不和 服务器 通讯， 你的 origin/master 指针 仍然保 持原位 
不 会移动 （ 见图 3- 2 3 ) 。 

可 以运行 git fetch origin 来 同步远 程服务 器上的 数据到 本地。 该 命令首 先找到 origin 是哪 
个 服务器 （本 例为 git.ourcompany.com ) , 从上 面获取 你尚未 拥有的 数据， 更 新你本 地的数 
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gtt.ourcompany.com 



( 0b743 )^~( a6b4cj-<-^ f42c5 ) 



git clone schacon^git . ourcompany . com: pro ject . git 



My Computer 



origin/master 

T 



( 0b743 a6b4c f42c5 ) 



t 



Remote Branch 



Local Branch 



图 3.22: — 次 Git 克 隆会建 立你自 己的本 地分支 master 和远 程分支 origin/master, 并且 
将它们 都指向 oHgin 上的 master 分支。 



gitourcompany.com 



( 。t>7" «6Mc £42cS < 31b" ) "*~ ^W。" ) " 



Someone e*se pushes 



My Computer 




图 3.23: 在本地 工作的 同时有 人向远 程仓库 推送内 容会让 提交历 史开始 分流。 



据库， 然后把 origin/master 的指针 移到它 最新的 位置上 （ 见图 3-24 ) 。 

为了演 示拥有 多个远 程分支 （在不 同的远 程服务 器上） 的 项目是 如何工 作的， 我 们假设 
你还有 另一个 仅供你 的敏捷 开发小 组使用 的内部 服务器 git.team1.ourcompany.com。 可以用 
第 二章中 提到的 git remote add 命令把 它加为 当前项 目的远 程分支 之一。 我 们把它 命名为 
teamone, 以 便代替 完整的 Git URL 以方 便使用 （ 见图 3-25 ) 。 

现在你 可以用 git fetch teamone 来获取 小组服 务器上 你还没 有的数 据了。 由于当 前该服 
务器 上的内 容是你 origin 服务 器上的 子集， Git 不会下 载任何 数据， 而只是 简单地 创建一 
个名为 teamone/master 的远程 分支， 指向 teamone 服 务器上 master 分支所 在的提 交对象 
31b8e ( 见图 3-26 ) 。 
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gtt.ourcompany.com 



( 。b7" "b 化 f42c5 ^^- 31b8e j^— ^"l90a3 ) 



git fetch origin 



My Computer 



origin /master 

T 



( 0b743 ) ^~ ( a6b4c^-^— ^f42c5 ^31b8e ) ^~ ( 190a3 ) 



)^~ ^ 893cfJ 



图 3.24: git fetch 命令 会更新 remote 索引 



git.ourcompany.com 



gitteaml .ourcompany.com 



remote add taaaoiM git://git.teaml.ourconipany.coa 



My Computer 




图 3.25: 把 另一个 服务器 加为远 程仓库 



3.5.1 推送本 地分支 

要想和 其他人 分享某 个本地 分支， 你 需要把 它推送 到一个 你拥有 写权限 的远程 仓库。 你创 
建 的本地 分支不 会因为 你的写 入操作 而被自 动同步 到你引 入的远 程服务 器上， 你需要 明确地 
执 行推送 分支的 操作。 换句 话说， 对 于无意 分享的 分支， 你 尽管保 留为私 人分支 好了， 而只 
推送 那些协 同工作 要用到 的特性 分支。 

如果你 有个叫 sen/erfix 的分 支需要 和他人 一起 开发， 可 以运行 git push (远 程仓 库名） （分支 
名)： 
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git.ourcompany.com 



origin 



gitteaml .ourcompany.com 






•* - < "2cS 31b8e ) 





git fetch teamonc 



T 



My Computer 








(umone / nusicr 


Ofigm/mauer 




^ 0b743 )•*-( »6Mc )■*— ( '«2c5 


h*~^ 31b8« )一 ( 190a3 ) 

( aJBde ( 893cf ) 

t 






master 





图 3.26: 你 在本地 有了一 个指向 teamone 服 务器上 master 分 支的索 5 



$ git push origin serverfix 
Counting objects: 20, done. 
Compressing objects: 100% (14/14), done. 
Writing objects: 100% (15/15), 1.74 KiB, done. 
Total 15 (delta 5), reused 0 (delta 0) 
To git@github.com:schacon/simplegit.git 
* [new branch] serverfix -> serverfix 



这里 其实走 了一点 捷径。 Git 自动把 serverfix 分支名 扩展为 re f s /heads/sen/erfix : refs/ 
heads/serverfix, 意为 "取 出我在 本地的 serverfix 分支， 推送 到远程 仓库的 serverfix 分支 
中去" 。 我们将 在第九 章进一 步介绍 ds/heads/ 部分的 细节， 不过一 般使用 的时候 都可以 
省 略它。 也可 以运行 git push origin serverfksen/erfix 来实现 相同的 效果， 它的 意思是 "上传 
我 本地的 serverfix 分 支到远 程仓库 中去， 仍旧 称它为 sen/erfix 分支" 。 通过此 语法， 你 
可 以把本 地分支 推送到 某个命 名不同 的远程 分支： 若想把 远程分 支叫作 awesomebranch, 可 
以用 git push origin serverfix:awesomebranch 来推送 数据。 

接 下来， 当 你的协 作者再 次从服 务器上 获取数 据时， 他 们将得 到一个 新的远 程分支 oHgin/ 
serverfix, 并 指向服 务器上 serverfix 所 指向的 版本： 



$ git fetch origin 

remote: Counting objects: 20, done, 
remote: Compressing objects: 100% (14/14)， done, 
remote: Total 15 (delta 5), reused 0 (delta 0) 
Unpacking objects: 100% (15/15), done. 
From git@github.com:schacon/simplegit 
* [new branch] serverfix -> origin/serverfix 



值 得注意 的是， 在 fetch 操作 下载好 新的远 程分支 之后， 你仍 然无法 在本地 编辑该 远程仓 
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库中的 分支。 换句 话说， 在本 例中， 你不 会有一 个新的 sen/erfix 分支， 有的只 是一个 你无法 
移动的 origin/serverfix 指针。 

如果 要把该 远程分 支的内 容合并 到当前 分支， 可 以运行 git merge origin/serverfix 0 如果想 
要一份 自己的 sen/^fix 来 开发， 可 以在远 程分支 的基础 上分化 出一个 新的分 支来： 

$ git checkout 一 b serverfix origin/serverfix 

Branch serverfix set up to track remote branch refs/ remotes/origin/serverfix. 
Switched to a new branch "serverfix" 



这会 切换到 新建的 sen/erfix 本地 分支， 其内 容同远 程分支 origin/sen/erfix —致， 这 样你就 
可以 在里面 继续开 发了。 

3.5.2 跟踪远 程分支 

从远 程分支 checkout 出来 的本地 分支， 称 为-跟 踪分支 (tracking branch)。 跟踪 分支是 
一种 和某个 远程分 支有直 接联系 的本地 分支。 在跟 踪分支 里输入 git push, Git 会自 行推断 
应该向 哪个服 务器的 哪个分 支推送 数据。 同样， 在这 些分支 里运行 git pull 会 获取所 有远程 
索引， 并把它 们的数 据都合 并到本 地分支 中来。 

在 克隆仓 库时， Git 通常 会自动 创建一 个名为 master 的分支 来跟踪 origin/master 这正是 
git push 和 git pull 一 开始就 能正常 工作的 原因。 当然， 你 可以随 心所欲 地设定 为其它 跟踪分 
支， 比如 origin 上除了 master 之外 的其它 分支。 刚才 我们已 经看到 了这样 的一个 例子： git 
checkout -b [分 支名] [远 程名] / [分支 名]。 如 果你有 1.6.2 以上 版本的 Git, 还 可以用 -track 选项 
简化： 

$ git checkout ― track origin/serverfix 

Branch serverfix set up to track remote branch refs/ remotes/origin/serverfix. 
Switched to a new branch "serverfix" 



要 为本地 分支设 定不同 于远程 分支的 名字， 只需 在第一 个版本 的命令 里换个 名字: 

$ git checkout - b sf origin/serverfix 

Branch sf set up to track remote branch refs/ remotes/origin/serverfix. 
Switched to a new branch "sf" 



现在 你的本 地分支 sf 会自 动将推 送和抓 取数据 的位置 定位到 origin/serverfix 了。 

3.5.3 删除远 程分支 

如果 不再需 要某个 远程分 支了， 比 如搞定 了某个 特性并 把它合 并进了 远程的 master 分支 

( 或任 何其他 存放稳 定代码 的分支 ） ， 可以用 这个非 常无厘 头的语 法来删 除它： git push [远 

程名] ： [分支 名]。 如 果想在 服务器 上删除 sen/erf ix 分支， 运行 下面的 命令： 
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$ git push origin :serverfix 
To git@github.com:schacon/simplegit.git 
一 [deleted] serverfix 



咚 ！ 服 务器上 的分支 没了。 你最 好特别 留心这 一页， 因 为你一 定会用 到那个 命令， 而且你 
很可 能会忘 掉它的 语法。 有种 方便记 忆这条 命令的 方法： 记 住我们 不久前 见过的 git push [远 
程名] [本地 分支] ： [远程 分支] 语法， 如 果省略 [本 地分 支], 那 就等于 是在说 "在 这里 提取空 白然后 
把 它变成 [远 程分 支]" 。 



3.6 分支 的衍合 

把一个 分支中 的修改 整合到 另一个 分支的 办法有 两种： merge 和 rebase (译注 ： rebase 的 
翻译 暂定为 "衍 合" ， 大家知 道就可 以了。 ） 。 在本 章我们 会学习 什么是 衍合， 如何 使用衍 
合， 为什 么衍合 操作如 此富有 魅力， 以及 我们应 该在什 么情况 下使用 衍合。 

3.6.1 基 本的衍 合操作 

请回顾 之前有 关合并 的一节 （ 见图 3-27 ) , 你会看 到开发 进程分 叉到两 个不同 分支， 又 
各自 提交了 更新。 



I 




图 3.27: 最 初分叉 的提交 历史。 



之前介 绍过， 最容易 的整合 分支的 方法是 merge 命令， 它会把 两个分 支最新 的快照 （ C3 
和 C4 ) 以及 二者最 新的共 同祖先 （ C2 ) 进 行三方 合并， 合并的 结果是 产生一 个新的 提交对 
象 （ C5 ) 。 如图 3-28 所示： 



， 




t 



图 3.28: 通过合 并一个 分支来 整合分 叉了的 历史。 
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其实， 还有另 外一个 选择： 你可 以把在 C3 里产生 的变化 补丁在 C4 的基 础上重 新打一 
遍。 在 Git 里， 这种操 作叫做 -衍合 （ rebase ) -。 有了 rebase 命令， 就可以 把在一 个分支 
里 提交的 改变移 到另一 个分支 里重放 一遍。 

在上面 这个例 子中， 运行： 



$ git checkout experiment 
$ git rebase master 

First, rewinding head to replay your work on top of it... 
Applying: added staged command 



它 的原理 是回到 两个分 支最近 的共同 祖先， 根据当 前分支 （也就 是要进 行衍合 的分支 

experiment) 后续的 历次提 交对象 （这 里只 有一个 C3 ) , 生 成一系 列文件 补丁， 然 后以基 
底分支 （也 就是主 干分支 master) 最后一 个提 交对象 （ C4 ) 为 新的出 发点， 逐个应 用之前 
准备好 的补丁 文件， 最后会 生成一 个新的 合并提 交对象 （ C3' ) , 从 而改写 experiment 的 
提交 历史， 使 它成为 master 分支 的直接 下游， 如图 3-29 所示： 



f \ experiment 



图 3.29: 把 C3 里 产生的 改变到 C4 上重演 一遍。 
现 在回到 master 分支， 进行 一次快 进合并 （ 见图 3-30 ) ： 



A 



图 3.30: master 分支的 快进。 

现在的 C3' 对应的 快照， 其实 和普通 的三方 合并， 即 上个例 子中的 C5 对应 的快 照内容 
一模一 样了。 虽然最 后整合 得到的 结果没 有任何 区别， 但 衍合能 产生一 个更为 整洁的 提交历 
史。 如果视 察一个 衍合过 的分支 的历史 记录， 看起 来会更 清楚： 仿佛所 有修改 都是在 一根线 
上 先后进 行的， 尽 管实际 上它们 原本是 同 时并行 发生的 。 

一般我 们使用 衍合的 目的， 是想要 得到一 个能在 远程分 支上干 净应用 的补丁 一 比 如某些 
项目你 不是维 护者， 但想 帮点忙 的活， 最好用 衍合： 先在自 己的一 个分支 里进行 开发， 当准 
备 向主项 目提交 补丁的 时候， 根据 最新的 oHgin/master 进行 一次衍 合操作 然后再 提交， 这 
样维护 者就不 需要做 任何整 合工作 （ 译注： 实际 上是把 解决分 支补丁 同最新 主干代 码之间 
冲突的 责任， 化转 为由提 交补丁 的人来 解决。 ） ， 只需根 据你提 供的仓 库地址 作一次 快进合 
并， 或 者直接 采纳你 提交的 补丁。 
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请 注意， 合并结 果中最 后一次 提交所 指向的 快照， 无论 是通过 衍合， 还 是三方 合并， 都会 
得 到相同 的快照 内容， 只不过 提交历 史不同 罢了。 衍合 是按照 每行的 修改次 序重演 一遍修 
改， 而合 并是把 最终结 果合在 一起。 

3.6.2 有趣 的衍合 

衍合 也可以 放到其 他分支 进行， 并 不一定 非得根 据分化 之前的 分支。 以图 3-31 的历史 
为例， 我 们为了 给服务 器端代 码添加 一些功 能而创 建了特 性分支 server, 然 后提交 C3 和 
C4。 然 后又从 C3 的地 方再增 加一个 client 分支来 对客户 端代码 进行一 些相应 修改， 所以提 
交了 C8 和 C9。 最后， 又回到 server 分支 提交了 C10。 




client 



图 3.31: 从一个 特性分 支里再 分出一 个特性 分支的 历史。 

假设在 接下来 的一次 软件发 布中， 我们决 定先把 客户端 的修改 并到主 线中， 而暂缓 并入服 
务 端软件 的修改 （因为 还需要 进一步 测试） 。 这个 时候， 我们 就可以 把基于 sen/er 分支而 
非 master 分支 的改变 （ 即 C8 禾 [] C9 ) , 跳过 server 直 接放到 master 分支 中重演 一遍， 但 
这 需要用 git rebase 的 一onto 选 项指定 新的基 底分支 master: 



$ git rebase ― onto master server client 



这好比 在说： "取出 client 分支， 找出 client 分支和 server 分 支的共 同祖先 之后的 变化， 
然后把 它们在 master 上重演 一遍" 。 是不 是有点 复杂？ 不过 它的结 果如图 3-32 所示， 非常 
酷 （ 译注： 虽然 client 里的 C8, C9 在 C3 之后， 但这仅 表明时 间上的 先后， 而非在 C3 修 
改的 基础上 进一步 改动， 因为 server 和 client 这两个 分支对 应的代 码应该 是两套 文件， 虽然 
这么说 不是很 严格， 但应理 解为在 C3 时间点 之后， 对另外 的文件 所做的 C8, C9 修改， 
放 到主干 重演。 ） ： 

现在可 以快进 master 分支了 （ 见图 3-33 ) ： 

$ git checkout master 
$ git merge client 
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图 3.33: 快进 master 分支， 使 之包含 client 分支的 变化。 

现 在我们 决定把 server 分支 的变化 也包含 进来。 我 们可以 直接把 sen/er 分支 衍合到 
master, 而不 用手工 切换到 server 分 支后再 执行衍 合操作 一 git rebase [主 分支] [特性 分支] 命 
令会先 取出特 性分支 sen/er, 然后在 主分支 master 上 重演： 



$ git rebase master server 



是， server 的进度 应用到 master 的基 础上， 如图 3-34 所示: 




图 3.34: 在 master 分支 上衍合 server 分支。 



然后 就可以 快进主 干分支 master 了: 
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$ git checkout master 
$ git merge server 

现在 client 和 server 分支的 变化都 已经集 成到主 干分支 来了， 可以 删掉它 们了。 最 终我们 
的提交 历史会 变成图 3-35 的 样子： 

$ git branch - d client 
$ git branch - d server 




图 3.35: 最 终的提 交历史 



3.6.3 衍合 的风险 

呃， 奇 妙的衍 合也并 非完美 无缺， 要用 它得遵 守一条 准则： 
一旦分 支中的 提交对 象发布 到公共 仓库， 就 千万不 要对该 分支进 行衍合 操作。 
如果你 遵循这 条金科 玉律， 就 不会出 差错。 否则， 人民群 众会仇 恨你， 你的 朋友和 家人也 
会嘲 笑你， 唾 弃你。 

在进行 衍合的 时候， 实际上 抛弃了 一些现 存的提 交对象 而创造 了一些 类似但 不同的 新的提 
交 对象。 如 果你把 原来分 支中的 提交对 象发布 出去， 并 且其他 人更新 下载后 在其基 础上开 

展 工作， 而稍后 你又用 git rebase 抛弃这 些提交 对象， 把 新的重 演后的 提交对 象发布 出去的 
话， 你 的合作 者就不 得不重 新合并 他们的 工作， 这样 当你再 次从他 们那里 获取内 容时， 提交 
历 史就会 变得一 团糟。 

下 面我们 用一个 实际例 子来说 明为什 么公开 的衍合 会带来 问题。 假设 你从一 个中央 服务器 
克隆然 后在它 的基础 上搞了 一些 开发， 提 交历史 类似图 3-36 所示： 

现在， 某人在 C1 的 基础上 做了些 改变， 并 合并他 自己的 分支得 到结果 C6, 推送 到中央 
服 务器。 当你 抓取并 合并这 些数据 到你本 地的开 发分支 中后， 会 得到合 并结果 C7, 历史提 
交会 变成图 3-37 这样： 

接 下来， 那 个推送 C6 上 来的人 决定用 衍合取 代之前 的合并 操作； 继 而又用 git push -- 
force 覆盖 了服务 器上的 历史， 得到 C4' 。 而 之后当 你再从 服务器 上下载 最新提 交后， 会得 
到： 

下 载更新 后需要 合并， 但此时 衍合产 生的提 交对象 C4' 的 SHA-1 校验值 和之前 C4 完 
全 不同， 所以 Git 会把它 们当作 新的提 交对象 处理， 而实际 上此刻 你的提 交历史 C7 中早已 
经 包含了 C4 的修改 内容， 于是 合并操 作会把 C7 和 C4' 合并为 C8 ( 见图 3-39 ) ： 

C8 这一 步的合 并是迟 早会发 生的， 因为 只有这 样你才 能和其 他协作 者提交 的内容 保持同 
步。 而在 C8 之后， 你 的提交 历史里 就会同 时包含 C4 和 C4' , 两 者有着 不同的 SHA-1 
校 验值， 如果用 git log 查看 历史， 会看 到两个 提交拥 有相同 的作者 日期与 说明， 令人 费解。 
而更糟 的是， 当 你把这 样的历 史推送 到服务 器后， 会再次 把这些 衍合后 的提交 引入到 中央服 
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git.teaml .ourcompany.com 




My Computer 




图 3.36: 克 隆一个 仓库， 在 其基础 上工作 一番。 



git. team 1 .ourcompany.com 




My Computer 



teamonc/masier 



H3^(Z) - 



图 3.37: 抓 取他人 提交， 并 入自己 主干。 



glt.team1 .ourcompany.com 




图 3.38: 有人 推送了 衍合后 得到的 C4' , 丢弃 了你作 为开发 基础的 C4 和 C6。 



务器， 进一 步困扰 其他人 （译注 ： 这个例 子中， 出 问题的 责任方 是那个 发布了 C6 后又 用衍 
合发布 C4' 的人， 其他人 会因此 反馈双 重历史 到共享 主干， 从 而混淆 大家的 视听。 ） 。 
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gltteaml .ourcompany.com 




图 3.39: 你把 相同的 内容又 合并了 一遍， 生成 一个新 的提交 C8。 

如果把 衍合当 成一种 在推送 之前清 理提交 历史的 手段， 而且仅 仅衍合 那些尚 未公开 的提交 
对象， 就没 问题。 如 果衍合 那些已 经公开 的提交 对象， 并 且已经 有人基 于这些 提交对 象开展 
了 后续开 发工作 的活， 就会出 现叫人 沮丧的 麻烦。 

3.7 小结 

读到 这里， 你 应该已 经学会 了如何 创建分 支并切 换到新 分支， 在不同 分支间 转换， 合并本 
地 分支， 把 分支推 送到共 享服务 器上， 使用共 享分支 与他人 协作， 以 及在分 享之前 进行衍 

合 
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到目前 为止， 你 应该已 经学会 了使用 Git 来完 成日常 工作。 然而， 如果想 与他人 合作， 还 
需 要一个 远程的 Git 仓库。 尽管技 术上可 以从个 人的仓 库里推 送和拉 取修改 内容， 但 我们不 
鼓励这 样做， 因 为一不 留心就 很容易 弄混其 他人的 进度。 另外， 你也一 定希望 合作者 们即使 
在自己 不开机 的时候 也能从 仓库获 取数据 一 拥有 一个更 稳定的 公共仓 库十分 有用。 因此， 
更 好的合 作方式 是建立 一个大 家都可 以访问 的共享 仓库， 从那 里推送 和拉取 数据。 我 们将把 
这个仓 库称为 "Git 服 务器" ； 代 理一个 Git 仓 库只需 要花费 很少的 资源， 几 乎从不 需要整 
个服务 器来支 持它的 运行。 

架 设一台 Git 服 务器并 不难。 第 一步是 选择与 服务器 通讯的 协议。 本 章第一 节将介 绍可用 
的协 议以及 各自优 缺点。 下面 一节将 介绍一 些针对 各个协 议典型 的设置 以及如 何在服 务器上 
实施。 最后， 如果 你不介 意在他 人服务 器上保 存你的 代码， 又想 免去自 己架设 和维护 服务器 
的 麻烦， 倒 可以试 试我们 介绍的 几个仓 库托管 服务。 

如 果你对 架设自 己的服 务器没 兴趣， 可以 跳到本 章最后 一节去 看看如 何申请 一个代 码托管 
服 务的账 户然后 继续下 一章， 我们 会在那 里讨论 分布式 源码控 制环境 的林林 总总。 

远程 仓库通 常只是 一个- 裸仓库 （bare repository ) - - 即一 个没 有当前 工作目 录的仓 
库。 因为 该仓库 只是一 个合作 媒介， 所 以不需 要从硬 盘上取 出最新 版本的 快照； 仓库 里存放 
的 仅仅是 Git 的 数据。 简单 地说， 裸仓 库就是 你工作 目录中 .git 子目 录内的 内容。 



4.1 协议 

Git 可以 使用四 种主要 的协议 来传输 数据： 本地 传输， SSH 协议， Git 协议和 HTTP 协 
议。 下 面分别 介绍一 下哪些 情形应 该使用 （ 或避 免使用 ） 这些 协议。 

值 得注意 的是， 除了 HTTP 协 议外， 其 他所有 协议都 要求在 服务器 端安装 并运行 Git。 

4.1.1 本 地协议 

最基 本的就 是-本 地协议 （Local protocol ) -, 所 谓的远 程仓库 在该协 议中的 表示， 就是 
硬 盘上的 另一个 目录。 这常 见于团 队每一 个成 员都对 一个共 享的文 件系统 （例如 NFS) 拥 
有访 问权， 或者 比较少 见的多 人共用 同一台 电脑的 情况。 后面 一种情 况并不 安全， 因 为所有 
代码 仓库实 例都储 存在同 一台电 脑里， 增加了 灾难性 数据损 失的可 能性。 

如果你 使用一 个共享 的文件 系统， 就可以 在一个 本地文 件系统 中克隆 仓库， 推送和 获取。 
克隆的 时候只 需要将 远程仓 库的路 径作为 URL 使用， 比 如下面 这样： 
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$ git clone /opt/git/project.git 



或者 这样: 



$ git clone file:///opt/g it/project. git 



如果在 URL 开头明 确使用 file:// , 那么 Git 会以 一种略 微不同 的方式 运行。 如果 你只给 
出 路径， Git 会尝试 使用硬 链接或 直接复 制它所 需要的 文件。 如果 使用了 file:// , Git 会调 
用它 平时通 过网络 来传输 数据的 工序， 而 这种方 式的效 率相对 较低。 使用 file:// 前缀 的主要 
原因 是当你 需要一 个不包 含无关 引用或 对象的 干净仓 库副本 的时候 —— 般指 从其他 版本控 
制 系统导 入的， 或类 似情形 （ 参见第 9 章 的维 护任务 ） 。 我 们这里 仅仅使 用普通 路径， 这样 
更快。 

要 添加一 个本地 仓库作 为现有 Git 项目 的远程 仓库， 可以这 样做： 



$ git remote add local — proj /opt/git/project.git 



然 后就可 以像在 网络上 一样向 这个远 程仓库 推送和 获取数 据了。 
优点 

基 于文件 仓库的 优点在 于它的 简单， 同时 保留了 现存文 件的权 限和网 络访问 权限。 如果你 
的团队 已经有 一个全 体共享 的文件 系统， 建立 仓库就 十分容 易了。 你只 需把一 份裸仓 库的副 
本 放在大 家都能 访问的 地方， 然后 像对其 他共享 目录一 样设置 读写权 限就可 以了。 我 们将在 

下一节 "在 服务器 上部署 Git" 中 讨论如 何导出 一个裸 仓库的 副本。 

这也 是从别 人工作 目 录中 获取工 作成果 的快捷 方法。 假如你 和你的 同事在 一个项 目 中合 

作， 他们想 让你检 出一些 东西的 时候， 运 行类似 git pull /home/john/project 通 常会比 他们推 
送到服 务器， 而你 再从服 务器获 取简单 得多。 

缺点 

这种方 法的缺 点是， 与 基本的 网络连 接访问 相比， 难 以控制 从不同 位置来 的访问 权限。 如 
果 你想从 家里的 笔记本 电脑上 推送， 就 要先挂 载远程 硬盘， 这和 基于网 络连接 的访问 相比更 
加 困难和 缓慢。 

另 一个很 重要的 问题是 该方法 不一定 就是最 快的， 尤其是 对于共 享挂载 的文件 系统。 本地 
仓库 只有在 你对数 据访问 速度快 的时候 才快。 在同一 个服务 器上， 如果 二者同 时允许 Git 访 
问本地 硬盘， 通过 NFS 访问 仓库通 常会比 SSH 慢。 

4.1.2 SSH 协议 

Git 使 用的传 输协议 中最常 见的可 能就是 SSH 了。 这是因 为大多 数环境 已经支 持通过 
SSH 对 服务器 的访问 一 即便还 没有， 架设起 来也很 容易。 SSH 也是唯 一一 个同时 支持读 
写操作 的网络 协议。 另外 两个网 络协议 （HTTP 和 Git) 通常 都是只 读的， 所 以虽然 二者对 
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大多 数人都 可用， 但执 行写操 作时还 是需要 SSH。 SSH 同时 也是一 个验证 授权的 网络协 
议； 而因 为其普 遍性， 一般架 设和使 用都很 容易。 

通过 SSH 克隆一 个 Git 仓库， 你 可以像 下面这 样给出 ssh:// 的 URL: 



$ git clone ssh://user@server:project.git 




或者不 指明某 个协议 - 这时 Git 会默 认使用 SSH ： 



$ git clone user@server:project.git 




如果 不指明 用户， Git 会 默认使 用当前 登录的 用户名 连接服 务器。 



优点 

使用 SSH 的 好处有 很多。 首先， 如 果你想 拥有对 网络仓 库的写 权限， 基本 上不可 能不使 

用 SSH。 其次， SSH 架设相 对比较 简单一 SSH 守护 进程很 常见， 很 多网络 管理员 都有一 
些使用 经验， 而且 很多操 作系统 都自带 了它或 者相关 的管理 工具。 再次， 通过 SSH 进行访 
问是安 全的一 所有数 据传输 都是加 密和授 权的。 最后， 和 Git 及本 地协议 一样， SSH 也很 
高效， 会在 传输之 前尽可 能压縮 数据。 



缺点 

SSH 的限制 在于你 不能通 过它实 现仓库 的匿名 访问。 即使仅 为读取 数据， 人们也 必须在 
能通过 SSH 访问主 机的前 提下才 能访问 仓库， 这使得 SSH 不利于 开源的 项目。 如 果你仅 
仅 在公司 网络里 使用， SSH 可能 是你唯 一需要 使用的 协议。 如 果想允 许对项 目的匿 名只读 
访问， 那么除 了为自 己推送 而架设 SSH 协议 之外， 还 需要支 持其他 协议以 便他人 访问读 

取。 



4.1.3 Git mx 

接 下来是 Git 协议。 这 是一个 包含在 Git 软件包 中的特 殊守护 进程； 它会 监听一 个提供 
类似于 SSH 服 务的特 定端口 （ 9418 ) , 而无 需任何 授权。 打 算支持 Git 协议的 仓库， 需要 
先创建 git-export-daemon-ok 文件 一 它是 协议进 程提供 仓库服 务的必 要条件 一 但除 此之外 
该服务 没有什 么安全 措施。 要么所 有人都 能克隆 Git 仓库， 要 么谁也 不能。 这 也意味 着该协 
议通常 不能用 来进行 推送。 你 可以允 许推送 操作； 然而 由于没 有授权 机制， 一旦允 许该操 
作， 网络 上任何 一个知 道项目 URL 的 人将都 有推送 权限。 不 用说， 这 是十分 罕见的 情况。 



优点 

Git 协 议是现 存最快 的传输 协议。 如果 你在提 供一个 有很大 访问量 的公共 项目， 或 者一个 
不需 要对读 操作进 行授权 的庞大 项目， 架 设一个 Git 守护 进程来 供应仓 库是个 不错的 选择。 
它 使用与 SSH 协议相 同的数 据传输 机制， 但 省去了 加密和 授权的 开销。 
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缺点 

Git 协议消 极的一 面是缺 少授权 机制。 用 Git 协 议作为 访问项 目的唯 一方法 通常是 不可取 
的。 一 般的做 法是， 同 时提供 SSH 接口， 让 几个开 发者拥 有推送 （ 写 ） 权限， 其他 人通过 
git:// 拥 有只读 权限。 Git 协议 可能也 是最难 架设的 协议。 它要求 有单独 的守护 进程， 需要 
定制 一 我 们将在 本章的 "Gitosis" — 节详细 介绍它 的架设 一 需 要设定 xinetd 或 类似的 
程序， 而 这些工 作就没 那么轻 松了。 该协 议还要 求防火 墙开放 9418 端口， 而 企业级 防火墙 
一般 不允许 对这个 非标准 端口的 访问。 大型企 业级防 火墙通 常会封 锁这个 少见的 端口。 

4.1.4 HTTP/S 协议 

最 后还有 HTTP 协议。 HTTP 或 HTTPS 协 议的优 美之处 在于架 设的简 便性。 基本上 
只 需要把 Git 的裸 仓库文 件放在 HTTP 的根目 录下， 配 置一个 特定的 post-update 挂钩 
( hook ) 就可 以搞定 （ Git 挂 钩的细 节见第 7 章 ） 。 此后， 每个 能访问 Git 仓 库所在 服务器 
上 web 服务 的人都 可以进 行克隆 操作。 下面 的操作 可以允 许通过 HTTP 对仓 库进行 读取： 

$ cd / var/ www/htdocs/ 

$ git clone ― bare /path/to/git— project gitproject.git 
$ cd gitproject.git 

$ mv hooks/ post-update.sample hooks/ post-update 
$ chmod a+x hooks/ post-update 

这 样就可 以了。 Git 附带的 post- update 挂钩会 默认运 行合适 的命令 （git update-server- 
info) 来确 保通过 HTTP 的获 取和克 隆正常 工作。 这 条命令 在你用 SSH 向仓 库推送 内容时 
运行； 之后， 其他人 就可以 用下面 的命令 来克隆 仓库： 



$ git clone http://example.com/gitproject.git 



在本 例中， 我们 使用了 Apache 设定中 常用的 /var/www/htdocs 路径， 不 过你可 以使用 
任 何静态 web 服务 一 把裸 仓库放 在它的 目录里 就行。 Git 的 数据是 以最基 本的静 态文件 
的形式 提供的 （ 关 于如何 提供文 件的详 情见第 9 章 ） 。 

通过 HTTP 进行推 送操作 也是可 能的， 不过 这种做 法不太 常见， 并且 牵扯到 复杂的 
WebDAV 设定。 由 于很少 用到， 本 书将略 过对该 内容的 讨论。 如果对 HTTP 推 送协议 
感 兴趣， 不 妨打开 这个地 址看一 下操作 方法： htt P :〃 WWW .kemel.org/pub/soft W are/scm/git/ 
docs/howto/setup- git- server- over- http.txt 。 通过 HTTP 推送的 好处之 一是你 可以使 用任何 
WebDAV 服 务器， 不 需要为 Git 设 定特殊 环境； 所 以如果 主机提 供商支 持通过 WebDAV 
更 新网站 内容， 你也 可以使 用这项 功能。 

优点 

使用 HTTP 协议 的好处 是易于 架设。 几条必 要的命 令就可 以让全 世界读 取到仓 库的内 
容。 花费 不过几 分钟。 HTTP 协议 不会占 用过多 服务器 资源。 因为 它一般 只用到 静态的 
HTTP 服务提 供所有 数据， 普通的 Apache 服务 器平均 每秒能 支撑数 千个文 件的并 发访问 
- 哪 怕让一 个小型 服务器 超载都 很难。 



78 



Scott Chacon Pro Git 



4.2 节 在 服务器 上部署 Git 



你也可 以通过 HTTPS 提供 只读的 仓库， 这意 味着你 可以加 密传输 内容； 你 甚至可 以要求 
客 户端使 用特定 签名的 SSL 证书。 一般情 况下， 如果 到了这 一步， 使用 SSH 公共密 钥可能 
是更 简单的 方案； 不过也 存在一 些特殊 情况， 这 时通过 HTTPS 使用带 签名的 SSL 证书或 
者其 他基于 HTTP 的只读 连接授 权方式 是更好 的解决 方案。 

HTTP 还有个 额外的 好处： HTTP 是一 个如此 常见的 协议， 以 至于企 业级防 火墙通 常都允 
许其 端口的 通信。 

缺点 

HTTP 协议的 消极面 在于， 相对来 说客户 端效率 更低。 克隆或 者下载 仓库内 容可能 会花费 
更多 时间， 而且 HTTP 传 输的体 积和网 络开销 比其他 任何一 个协议 都大。 因 为它没 有按需 
供应 的能力 一 传输过 程中没 有服务 端的动 态计算 一 因而 HTTP 协议 经常会 被称为 -傻瓜 
( dumb ) 4 办议。 更多 HTTP 协议和 其他协 议效率 上的差 异见第 9 章 。 



4.2 在 服务器 上部署 Git 

开 始架设 Git 服务 器前， 需要 先把现 有仓库 导出为 裸仓库 一 即一个 不包含 当前工 作目录 
的 仓库。 做 法直截 了当， 克 隆时用 一bare 选项 即可。 裸仓 库的目 录名一 般以. git 结尾， 像 
这样： 

$ git clone ― bare my— project my_project.git 

Initialized empty Git repository in / opt/ projects/ my_project.git/ 



该 命令的 输出或 许会让 人有些 不解。 其实 done 操作 基本上 相当于 git init 加 git fetch, 所 
以这里 出现的 其实是 git init 的 输出， 先由 它建立 一个空 目录， 而之后 传输数 据对象 的操作 
并 无任何 输出， 只 是悄悄 在幕后 执行。 现在 m V _ pr0 j eCt .gi t 目录中 已经有 了一份 Git 目录数 
据的 副本。 

整体上 的效果 大致相 当于： 



$ cp -Rf my-project/.git my_project.git 



但在 配置文 件中有 若干小 改动， 不过 对用户 来讲， 使用 方式都 一样， 不会 有什么 影响。 它 
仅取出 Git 仓 库的必 要原始 数据， 存放 在该目 录中， 而不会 另外创 建工作 目录。 

4.2.1 把 裸仓库 移到服 务器上 

有 了裸仓 库的副 本后， 剩下的 就是把 它放到 服务器 上并设 定相关 协议。 假 设一个 域名为 

git.example.com 的 服务器 已经架 设好， 并可 以通过 SSH 访问， 我 们打算 把所有 Git 仓库储 
存在 /opt/git 目 录下。 只要 把裸仓 库复制 过去： 



$ scp -r my-project.git user@git.example.com:/opt/git 
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现在， 所有 对该服 务器有 SSH 访问 权限， 并 可读取 /opt/git 目录的 用户都 可以用 下面的 
命令 克隆该 项目： 



$ git clone user@g it. example. com:/opt/git/my_project. git 



如 果某个 SSH 用户对 /o P t/git/m y _ pr0 j eC t.git 目 录有写 权限， 那他就 有推送 权限。 如果到 
该项 目目录 中运行 git init 命令， 并加上 一shared 选项， 那么 Git 会自 动修改 该仓库 目录的 
组权限 为可写 ( 译注： 实际上 一shared 可以指 定其他 行为， 只 是默认 为将组 权限改 为可写 
并执行 g+sx, 所 以最后 会得到 ™s。 ) 。 

$ ssh user@git.example.com 
$ cd /opt/git/my-project.git 
$ git init 一- bare -- shared 



由此 可见， 根据 现有的 Git 仓 库创建 一个裸 仓库， 然后把 它放上 你和同 事都有 SSH 访问 
权 的服务 器是多 么容易 。 现在已 经可以 开始在 同一项 目 上 密切合 作了。 

值 得注意 的是， 这 的的确 确是架 设一个 少数人 具有连 接权的 Git 服务 的全部 一 只 要在服 
务器 上加入 可以用 SSH 登录的 帐号， 然后 把裸仓 库放在 大家都 有读写 权限的 地方。 一切都 

准备 停当， 无需 更多。 

下 面的几 节中， 你 会了解 如何扩 展到更 复杂的 设定。 这 些内容 包含如 何避免 为每一 个用户 

建 立一个 账户， 给仓库 添加公 共读取 权限， 架 设网页 界面， 使用 Gitosis 工具 等等。 然而， 
只是和 几个人 在一个 不公开 的项目 上合作 的活， 仅仅 是一个 SSH 服 务器和 裸仓库 就足够 
了， 记住这 点就可 以了。 

4.2.2 小 型安装 

如果设 备较少 或者你 只想在 小型开 发团队 里尝试 Git , 那么一 切都很 简单。 架设 Git 服 
务最 复杂的 地方在 于账户 管理。 如果需 要仓库 对特定 的用户 可读， 而给 另一部 分用户 读写权 
限， 那 么访问 和许可 的安排 就比较 困难。 

SSH 连接 

如果已 经有了 一个所 有开发 成员都 可以用 SSH 访 问的服 务器， 架设 第一个 服务器 将变得 
异常 简单， 几乎 什么都 不用做 （ 正 如上节 中介绍 的那样 ） 。 如果 需要对 仓库进 行更复 杂的访 
问 控制， 只要 使用服 务器操 作系统 的本地 文件访 问许可 机制就 行了。 

如果 需要团 队里的 每个人 都对仓 库有写 权限， 又不 能给每 个人在 服务器 上建立 账户， 那 
么提供 SSH 连接 就是唯 一的选 择了。 我 们假设 用来共 享仓库 的服务 器已经 安装了 SSH 服 
务， 而且你 通过它 访问服 务器。 

有好几 个办法 可以让 团队的 每个人 都有访 问权。 第一 个办法 是给每 个人建 立一个 账户， 直 
截了当 但略过 繁琐。 反 复运行 adduser 并给所 有人设 定临时 密码可 不是好 玩的。 

第二 个办法 是在主 机上建 立一个 git 账户， 让每 个需要 写权限 的人发 送一个 SSH 公钥， 
然后将 其加入 git 账户的 V.ssh/authorizecLkeys 文件。 这样一 来， 所 有人都 将通过 git 账户 
访问 主机。 这丝毫 不会影 晌提交 的数据 一 访问主 机用的 身份不 会影响 提交对 象的提 交者信 

詹、 。 
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4.3 节 生成 SSH 公钥 



另 一个办 法是让 SSH 服 务器通 过某个 LDAP 服务， 或者其 他已经 设定好 的集中 授权机 
制， 来进行 授权。 只要每 个人都 能获得 主机的 shell 访 问权， 任何 可用的 SSH 授权 机制都 
能达 到相同 效果。 

4.3 生成 SSH 公钥 

大多数 Git 服务器 都会选 择使用 SSH 公钥 来进行 授权。 系统 中的每 个用户 都必须 提供一 
个公 钥用于 授权， 没有 的活就 要生成 一个。 生成 公钥的 过程在 所有操 作系统 上都差 不多。 
首先先 确认一 下是否 已经有 一个公 钥了。 SSH 公钥默 认储存 在账户 的主目 录下的 V.ssh 目 
录。 进去 看看： 



$ cd ~/.ssh 




$ Is 




authorized — keys2 id-dsa 


known_hosts 


config id-dsa. pub 





关键 是看有 没有用 something 和 something.pub 来命名 的一对 文件， 这个 something 通常 
就是 id_dsa 或 id_r Sa 。 有 .pub 后 缀的文 件就是 公钥， 另 一个文 件则是 密钥。 假如没 有这些 
文件， 或者干 脆连. ssh 目录都 没有， 可以用 ssh-keygen 来 创建。 该 程序在 Linux/Mac 系 
统上由 SSH 包 提供， 而在 Windows 上则 包含在 MSysGit 包里： 

$ ssh-keygen 

Generating public/private rsa key pair. 

Enter file in which to save the key (/Users/schacon/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 

Your identification has been saved in /Users/schacon/.ssh/id_rsa. 
Your public key has been saved in /Users/schacon/.ssh/id — rsa.pub. 
The key fingerprint is: 

43:c5:5b:5f:b1:f1:50:43:ad:20:a6:92:6a:1f:9a:3a schacon@agadorlaptop.local 




它先 要求你 确认保 存公钥 的位置 （.ssh/id_ rsa ) ， 然后它 会让你 重复一 个密码 两次， 如果 
不想在 使用公 钥的时 候输入 密码， 可以 留空。 

现在， 所 有做过 这一步 的用户 都得把 它们的 公钥给 你或者 Git 服 务器的 管理员 （假设 
SSH 服 务被设 定为使 用公钥 机制） 。 他 们只需 要复制 .pub 文 件的内 容然后 发邮件 给管理 
员。 公 钥的样 子大致 如下： 

$ cat ~/.ssh/id — rsa.pub 

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTlpNLTGK9Tjom/BWDSU 

GPI+nafzlHDTYW7hdl4yZ5ew18JH4JW9jbhUFrviQzM7xlELEVf4h9IFX5QVkbPppSwg0cda3 

Pbv7kOdJ/MTyBIWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSIVK/7XA 
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t3FaoJoAsncM1Q9x5+3V0Ww68/elFmb1zuUFIjQJKprrX88XypNDvjYNby6vw/Pb0rwert/En 
mZMW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmlkjn2so1d01QraTIMqVSsbx 
NrRFi9wrf+M7Q== schacon@agadorlaptop. local 



关于 在多个 操作系 统上设 立相同 SSH 公钥的 教程， 可 以查阅 GitHub 上有关 SSH 公钥 
的 向导： 。 



4.4 架设 服务器 

现 在我们 过一边 服务器 端架设 SSH 访问的 流程。 本例 将使用 authorized-keys 方法 来给用 
户 授权。 我 们还将 假定使 用类似 Ubumu 这样 的标准 Linux 发 行版。 首先， 创建一 个名为 
'git' 的 用户, 并为 其创建 一个. ssh 目录。 



$ sudo adduser git 
$ su git 
$ cd 

$ mkdir .ssh 




接 下来， 把开 发者的 SSH 公 钥添加 到这个 用户的 authorizecLkevs 文 件中。 假设你 通过电 
邮收到 了几个 公钥并 存到了 临时文 件里。 重复 一下， 公 钥大致 看起来 是这个 样子： 



$ cat /tmp/id-rsa.john.pub 

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L 

ojG6rs6hPB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4k 

Yjh6541NYsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rflF1kKI9MAQLMdpGW1GYEIgS9Ez 

Sdfd8AcClicTDWbqLAcU4UpkaX8KyGILwsNuuGztobF8m72ALC/nLF6JLtPofwFBIgc+myiv 

O7TCUSBdLQIgMVOFq1l2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq 

dAv8JggJICUvax2T9va5 gsg-keypair 



只 要把它 们逐个 追加到 authorizecLkeys 文 件尾部 即可: 



$ cat /tmp/id-rsa.john.pub » ~/.ssh/authorized — keys 
$ cat /tmp/id — rsa.josie.pub » -/.ssh/authorized-keys 
$ cat /tmp/id-rsa.jessica.pub » -/.ssh/authorized-keys 




现在 可以用 一bare 选 项运行 git init 来建立 一个裸 仓库， 这会 初始化 一个不 包含工 作目录 
的 仓库。 
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4.4 节 架设 服务器 



$ cd /opt/git 
$ mkdir project.git 
$ cd project.git 
$ git -- bare init 

这时， join, josie 或者 jessica 就可以 把它加 为远程 仓库， 推 送一个 分支， 从而 把第一 
个 版本的 项目文 件上传 到仓库 里了。 值 得注意 的是， 每次 添加一 个新项 目都需 要通过 shell 
登入主 机并创 建一个 裸仓库 目录。 我们 不妨以 gitsen/er 作为 git 用户及 项目仓 库所在 的主机 
名。 如 果在网 络内部 运行该 主机， 并在 DNS 中设定 gitserver 指向该 主机， 那 么以下 这些命 
令 都是可 用的： 



# 在 john 的 电脑上 
$ cd myproject 
$ git init 
$ git add . 

$ git commit -m 'initial commit' 

$ git remote add origin git@gitserver:/opt/git/project.git 
$ git push origin master 



这样， 其他人 的克隆 和推送 也一样 变得很 简单: 

$ git clone git@gitserver:/opt/git/project.git 
$ vim README 

$ git commit -am 'fix for the README file' 
$ git push origin master 



用这个 方法可 以很快 捷地为 少数几 个开发 者架设 一个可 读写的 Git 服务。 

作为一 个额外 的防范 措施， 你 可以用 Git 自带的 git-shell 工 具限制 git 用户 的活动 范围。 

只要把 它设为 git 用户 登入的 shell, 那 么该用 户就无 法使用 普通的 bash 或者 csh 什么的 

shell 程序。 编辑 /etc/passwd 文件： 

$ sudo vim /etc/passwd 



在文件 末尾， 你 应该能 找到类 似这样 的行： 

git:x:1000:1000::/home/git:/bin/sh 

把 bin/sh 改为 /usr/bin/git-shell ( 或者用 which git-shell 查 看它的 实际安 装路径 ） 。 该行 
修改后 的样子 如下： 

83 



第 4 章 服务 器上的 Git 



Scott Chacon Pro Git 



git:x:1000:1000::/home/git:/usr/bin/g it-shell 



现在 git 用户 只能用 SSH 连接 来推送 和获取 Git 仓库， 而不能 直接使 用主机 shell。 尝试 
普通 SSH 登录 的活， 会 看到下 面这样 的拒绝 信息： 

$ ssh git@gitserver 

fatal: What do you think I am? A shell? 
Connection to gitserver closed. 



4.5 公 共访问 

匿名 的读取 权限该 怎么实 现呢？ 也许 除了内 部私有 的项目 之外， 你还 需要托 管一些 开源项 
目。 或者因 为要用 一些自 动化的 服务器 来进行 编译， 或 者有一 些经常 变化的 服务器 群组， 而 

又不想 整天生 成新的 SSH 密钥 一 总之， 你 需要简 单的匿 名读取 权限。 

或许对 小型的 配置来 说最简 单的办 法就是 运行一 个静态 web 服务， 把它的 根目录 设定为 
Git 仓库 所在的 位置， 然后开 启本章 第一节 提到的 post-update 挂钩。 这里继 续使用 之前的 
例子。 假设仓 库处于 /opt/git 目录， 主机上 运行着 Apache 服务。 重申一 下， 任何 web 服 
务 程序都 可以达 到相同 效果； 作为 范例， 我们将 用一些 基本的 Apache 设定 来展示 大体需 
要的 步骤。 

首先， 开启 挂钩： 

$ cd project.git 

$ mv hooks/post-update. sample hooks/ post-update 
$ chmod a+x hooks/ post-update 

如果 用的是 Git 1.6 之前的 版本， 则可 以省略 mv 命令一 Git 是从较 晚的版 本才开 始在挂 
钩实 例的结 尾添加 .sample 后缀 名的。 

post-update 挂钩是 做什么 的呢？ 其内 容大致 如下： 

$ cat .git/hooks/post-update 
#!/bin/sh 

exec git- update— server- info 



意思是 当通过 SSH 向服 务器推 送时， Git 将运 行这个 git- update-server-info 命令来 更新匿 
名 HTTP 访问 获取数 据时所 需要的 文件。 

接 下来， 在 Apache 配置文 件中添 加一个 VirtualHost 条目， 把文 档根目 录设为 Git 项 
目所 在的根 目录。 这里我 们假定 DNS 服务 已经配 置好， 会把对 .gitsen/er 的请 求发 送到这 
台 主机： 
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<VirtualHost *:80> 

ServerName git.gitserver 
DocumentRoot /opt/git 
<Directory /opt/git/> 
Order allow, deny 
allow from all 
</Directory> 
</VirtualHost> 



另外， 需要把 /opt/git 目录的 Unix 用户组 设定为 www-data ， 这样 web 服务才 可以读 
取仓库 内容， 因 为运行 CG1 脚本的 Apache 实 例进程 默认就 是以该 用户的 身份起 来的： 



$ chgrp - R www-data /opt/git 



重启 Apache 之后， 就可 以通过 项目的 URL 来克隆 该目录 下的仓 库了。 



$ git clone http://git.gitserver/ project. git 



这 一招可 以让你 在几分 钟内为 相当数 量的用 户架设 好基于 HTTP 的读取 权限。 另 一个提 
供 非授权 访问的 简单方 法是开 启一个 Git 守护 进程， 不过 这将要 求该进 程作为 后台进 程常驻 

- 接下来 的这一 节就要 讨论这 方面的 细节。 



4.6 GitWeb 

现在我 们的项 目已经 有了可 读可写 和只读 的连接 方式， 不过 如果能 有一个 简单的 web 
界面访 问就更 好了。 Git 自带一 个叫做 GitWeb 的 CGI 脚本， 运 行效果 可以到 htt P: //git. 
kernel.org 这样 的站点 体验下 （ 见图 4-1 ) 。 
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图 4.1: 基于 网页的 GitWeb 用 户界面 
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如 果想看 看自己 项目的 效果， 不妨用 Git 自带的 一个 命令， 可以使 用类似 lighttpd 或 
webrick 这样轻 量级的 服务器 启动一 个临时 进程。 如 果是在 Linux 主机上 通常都 预装了 
lighttpd , 可 以到项 目目录 中键入 git instaweb 来启动 。如果 用的是 Mac , Leopard 预 
装了 Ruby, 所以 webrick 应该是 最好的 选择。 如 果要用 lighttpd 以外 的程序 来启动 git 
instaweb, 可以 通过 — httpd 选项 指定： 



$ git instaweb -- httpd=webrick 
[2009-02-21 10:02:21] INFO WEBrick 1.3.1 

[2009-02-21 10:02:21] INFO ruby 1.8.6 (2008-03-03) [universa 卜 darwin9.0] 




这会在 1234 端口开 启一个 HTTPD 服务， 随之在 浏览器 中显示 该页， 十分 简单。 关闭服 
务时， 只需在 原来的 命令后 面加上 一stop 选 项就可 以了： 



$ git instaweb -- httpd=webrick -- stop 



如 果需要 为团队 或者某 个开源 项目长 期运行 GitWeb, 那么 CGI 脚 本就要 由正常 的网页 
服务来 运行。 一些 Linux 发 行版可 以通过 apt 或 yum 安装一 个叫做 gitweb 的软 件包， 不 
妨首 先尝试 一下。 我 们将快 速介绍 一下手 动安装 GitWeb 的 流程。 首先， 你需要 Git 的源 
码， 其 中带有 GitWeb, 并 能生成 定制的 CGI 脚本： 



$ git clone git://git.kernel.org/pub/scm/g it/git. git 
$ cd git/ 

$ make GITWEB — PROJECTROOT='7opt/git" \ 

prefix=/usr gitweb/gitweb.cgi 
$ sudo cp -Rf gitweb /var/www/ 



注意， 通 过指定 GITWEB_PROjECTROOT 变量 告诉编 译命令 Git 仓库的 位置。 然后， 设置 
Apache 以 CGI 方式 运行该 脚本， 添 加一个 VirtualHost 配置： 

<VirtualHost *:80> 

ServerName gitserver 
DocumentRoot /var/www/gitweb 
<Directory / var/ www/ g itweb> 

Options ExecCGI +FollowSymLinks +SymLinkslfOwnerMatch 

AllowOverride All 

order allow, deny 

Allow from all 

AddHandler cgi- script cgi 

Directorylndex gitweb. cgi 
</Directory> 
</VirtualHost> 
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不难 想象， GitWeb 可以 使用任 何兼容 CGI 的网页 服务来 运行； 如果 偏向使 用其他 
web 服 务器， 配置也 不会很 麻烦。 现在， 通过 htt P: //git S en/ er 就可 以在线 访问仓 库了， 在 
http://git.ser V er 上还可 以通过 HTTP 克隆 和获取 仓库的 内容。 

4.7 Gitosis 

把所 有用户 的公钥 保存在 authorized — keys 文件的 做法， 只能 凑和一 阵子， 当 用户数 量达到 
几百 人的规 模时， 管理 起来就 会十分 痛苦。 每次改 删用户 都必须 登录服 务器不 去说， 这种做 
法还 缺少必 要的权 限管理 一 每 个人都 对所有 项目拥 有完整 的读写 权限。 

幸好 我们还 可以选 择应用 广泛的 Gitosis 项目。 简单 地说， Gitosis 就是 一套用 来管理 
authorized-keys 文件和 实现简 单连接 限制的 脚本。 有趣 的是， 用 来添加 用户和 设定权 限的并 
非通 过网页 程序， 而 只是管 理一个 特殊的 Git 仓库。 你只 需要在 这个特 殊仓库 内做好 相应的 
设定， 然 后推送 到服务 器上， Gitosis 就会 随之改 变运行 策略， 听 起来就 很酷， 对吧？ 

Gitosis 的 安装算 不上傻 瓜化， 但 也不算 太难。 用 Linux 服 务器架 设起来 最简单 一 以下 
例 子中， 我们使 用装有 Ubuntu 8.10 系 统的服 务器。 

Gitosis 的工 作依赖 于某些 Python 工具， 所 以首先 要安装 Python 的 setuptools 包， 在 
Ubuntu 上称为 python- setuptools: 

$ apt-get install python- setuptools 



接 下来， 从 Gitosis 项 目主页 克隆并 安装： 

$ git clone git://eaga in.net/gitosis.git 
$ cd gitosis 

$ sudo python setup. py install 

这 会安装 几个供 Gitosis 使用的 工具。 默认 Gitosis 会把 /home/git 作为存 储所有 Git 仓 
库的根 目录， 这 没什么 不好， 不 过我们 之前已 经把项 目仓库 都放在 /opt/git 里 面了， 所以为 
方便 起见， 我们可 以做一 个符号 连接， 直 接划转 过去， 而不 必重新 配置： 



$ In -s /opt/git /home/git/repositories 



Gitosis 将会帮 我们管 理用户 公钥， 所以先 把当前 控制文 件改名 备份， 以 便稍后 重新添 

力卩， 准 备好让 Gitosis 自 动管理 authorized — keys 文件： 



$ mv /home/git/.ssh/authorized-keys /home/git/.ssh/ak.bak 



接 下来， 如果 之前把 git 用户 的登录 shell 改为 git-shell 命令 的活， 先恢复 'git' 用户 
的登录 Shell。 改过 之后， 大 家仍然 无法通 过该帐 号登录 （译注 ： 因为 authorized — keys 文件 
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已经没 有了。 ） ， 不 过不用 担心， 这 会交给 Gitosis 来 实现。 所 以现在 先打开 /etc/passwd 
文件， 把 这行： 



git:x:1000:1000::/home/git:/usr/bin/g it-shell 



改回: 



git:x:1000:1000::/home/git:/bin/sh 



好了， 现 在可以 初始化 Gitosis 了。 你可 以用自 己的公 钥执行 gitosis- 
不 在服务 器上， 先临 时复制 一份： 



命令， 要 是公钥 



$ sudo -H - u git gitosis-init < /tmp/id-dsa.pub 

Initialized empty Git repository in /opt/git/gitosis-admin.git/ 

Reinitialized existing Git repository in /opt/git/gitosis-admin.git/ 



这样 该公钥 的拥有 者就能 修改用 于配置 Gitosis 的那 个特殊 Git 仓 库了。 接 下来， 需要 ^ 
工 对该仓 库中的 post- update 脚 本加上 可执行 权限： 




基本上 就算是 好了。 如 果设定 过程没 出什么 差错， 现在 可以试 一下用 初始化 Gitosis 的公 
钥 的拥有 者身份 SSH 登录服 务器， 应该会 看到类 似下面 这样： 



$ ssh git@gitserver 

PTY allocation request failed on channel 0 

fatal: unrecognized command 'gitosis- serve schacon@quaternion' 
Connection to gitserver closed. 



说明 Gitosis 认 出了该 用户的 身份， 但由于 没有运 行任何 Git 命令， 所以它 切断了 连接。 
那么， 现在运 行一个 实际的 Git 命令 一 克隆 Gitosis 的控制 仓库： 



# 在你 本地计 算机上 

$ git clone git@gitserver:gitosis-admin.git 




这会 得到一 个名为 gitosis-admin 的工作 目录， 主要由 两部分 组成: 
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$ cd gitosis- admin 
$ find . 
./gitosis. conf 
./keydir 

./keydir/scott.pub 

gitosis.conf 文 件是用 来设置 用户、 仓库 和权限 的控制 文件。 keydir 目 录则是 保存所 有具有 
访问权 限用户 公钥的 地方一 每人一 个。 在 keydir 里的 文件名 （ 比如 上面的 scott.pub ) 应该 
跟你的 不一样 一 Gitosis 会自动 从使用 gitosis-init 脚本 导入的 公钥尾 部的描 述中获 取该名 
字。 

看一下 gitosis.conf 文件的 内容， 它应该 只包含 与刚刚 克隆的 gitosis-admin 相关的 信息： 



$ cat gitosis.conf 




[gitosis] 




[group gitosis-admin] 




writable = gitosis-admin 




members = scott 





它显 示用户 scott ― 初始化 Gitosis 公钥的 拥有者 一 是唯一 能管理 gitosis-admin 项目的 
人。 

现 在我们 来添加 一个新 项目。 为此 我们要 建立一 个名为 mobile 的新 段落， 在其中 罗列手 
机 开发团 队的开 发者， 以 及他们 拥有写 权限的 项目。 由于 'SCOtt' 是 系统中 的唯一 用户， 
我们 把他设 为唯一 用户， 并允 许他读 写名为 i P h 0ne _ pr0 je C t 的新 项目： 



[group mobile] 

writable = iphone— project 

members = scott 



修改完 之后， 提交 gitosis-admin 里的 改动， 并推送 到服务 器使其 生效: 

$ git commit -am 'add iphone— project and mobile group' 
[master]: created 8962da8: "changed name" 
1 files changed, 4 insertions( + ), 0 deletions (-) 
$ git push 

Counting objects: 5, done. 

Compressing objects: 100% (2/2), done. 

Writing objects: 100% (3/3)， 272 bytes, done. 

Total 3 (delta 1), reused 0 (delta 0) 

To git@gitserver:/opt/git/gitosis-admin.git 
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fb27aec..8962da8 master -> master 

在 新工程 i P h 0ne _ pr0 j ec t 里 首次推 送数据 到服务 器前， 得先 设定该 服务器 地址为 远程仓 

库。 但你 不用事 先到服 务器上 手工创 建该项 目的裸 仓库一 Gitosis 会在 第一次 遇到推 送时自 
动 创建： 

$ git remote add origin git@gitserver:iphone_project.git 
$ git push origin master 

Initialized empty Git repository in /opt/git/iphone— project.git/ 
Counting objects: 3， done. 
Writing objects: 100% (3/3)， 230 bytes, done. 
Total 3 (delta 0)， reused 0 (delta 0) 
To git@gitserver:i phone- project.git 
* [new branch] master -> master 



请 注意， 这 里不用 指明完 整路径 （实 际上， 如果 加上反 而没用 ）， 只 需要一 个冒号 加项目 

名 字即可 一 Gitosis 会 自动帮 你映射 到实际 位置。 

要 和朋友 们在一 个项目 上协同 工作， 就得重 新添加 他们的 公钥。 不过 这次不 用在服 务器上 

—个一 个手工 添加到 V.ssh/authorizecLkevs 文件 末端， 而只 需管理 keydir 目 录中的 公钥文 
件。 文件的 命名将 决定在 gitosis.conf 中对 用户的 标识。 现在 我们为 john, Josie 和 jessica 
添加 公钥： 

$ cp /tmp/id-rsa.john.pub keydir/john.pub 
$ cp /tmp/id-rsa.josie.pub keydir/josie.pub 
$ cp /tmp/id-rsa.jessica.pub keydir/jessica.pub 



然后 把他们 都加进 'mobile' 团队， 让 他们对 i P h 0ne _ pr0 j ec t 具 有读写 权限: 

[group mobile] 

writable = iphone — project 

members = scott john josie jessica 



如 果你提 交并推 送这个 修改， 四个用 户将同 时具有 该项目 的读写 权限。 

Gitosis 也 具有简 单的访 问控制 功能。 如 果想让 john 只有读 权限， 可以这 样做: 

[group mobile] 

writable = iphone— project 

members = scott josie jessica 
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[group mobile— ro] 
readonly = iphone— project 
members = john 

现在 john 可 以克隆 和获取 更新， 但 Gitosis 不会允 许他向 项目推 送任何 内容。 像 这样的 
组可 以随意 创建， 多少 不限， 每个都 可以包 含若干 不同的 用户和 项目。 甚至还 可以指 定某个 
组为成 员之一 （ 在组名 前加上 @ 前 缀）， 自 动继承 该组的 成员： 

[group mobile— committers] 
members = scott josie jessica 

[group mobile] 

writable = iphone — project 

members = @mobile— committers 

[group mobile— 2] 

writable = another— iphone — project 
members = @mobile— committers john 

如果遇 到意外 问题， 试 试看把 loglevehDEBUG 加到 [gitosis] 的段落 （译注 ： 把日志 设置为 
调试 级别， 记录 更详细 的运行 信息。 ） 。 如果一 不小心 搞错了 配置， 失去 了推送 权限， 也可 
以 手工修 改服务 器上的 /home/git/.gitosis.conf 文件 ― Gitosis 实 际是从 该文件 读取信 息的。 
它 在得到 推送数 据时， 会 把新的 gitosis.conf 存 到该路 径上。 所 以如果 你手工 编辑该 文件的 
话， 它 会一直 保持到 下次向 gitosis- admin 推 送新版 本的配 置内容 为止。 

4.8 Gitolite 

Note: the latest copy of this section of the ProGit book is always available within 
the gitolite documentation. The author would also like to humbly state that, while this 
section is accurate, and can (and often has) been used to install gitolite without read- 
ing any other documentation, it is of necessity not complete, and cannot completely 
replace the enormous amount of documentation that gitolite comes with. 

Git has started to become very popular in corporate environments, which tend to 
have some additional requirements in terms of access control. Gitolite was originally 
created to help with those requirements, but it turns out that it' s equally useful in the 
open source world: the Fedora Project controls access to their package management 
repositories (over 10,000 of them!) using gitolite, and this is probably the largest 
gitolite installation anywhere too. 

Gitolite allows you to specify permissions not just by repository, but also by branch 
or tag names within each repository. That is, you can specify that certain people (or 
groups of people) can only push certain "refs" (branches or tags) but not others. 
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4.8.1 Installing 

Installing Gitolite is very easy, even if you don' t read the extensive documentation 
that comes with it. You need an account on a Unix server of some kind; various Linux 
flavours, and Solaris 10， have been tested. You do not need root access, assuming 
git, perl, and an openssh compatible ssh server are already installed. In the examples 
below, we will use the gitolite account on a host called gitserver. 

Gitolite is somewhat unusual as far as "server" software goes □ access is via ssh, 
and so every userid on the server is a potential "gitolite host" . As a result, there 
is a notion of "installing" the software itself, and then "setting up" a user as a 
"gitolite host" . 

Gitolite has 4 methods of installation. People using Fedora or Debian systems can 
obtain an RPM or a DEB and install that. People with root access can install it manually. 
In these two methods, any user on the system can then become a "gitolite host" . 

People without root access can install it within their own userids. And finally, gitolite 
can be installed by running a script on the workstation, from a bash shell. ( Even the 
bash that comes with msysgit will do, in case you' re wondering.) 

We will describe this last method in this article; for the other methods please see 
the documentation. 

You start by obtaining public key based access to your server, so that you can log in 
from your workstation to the server without getting a password prompt. The following 
method works on Linux; for other workstation OSs you may have to do this manually. 
We assume you already had a key pair generated using ssh-keygen. 



$ ssh- copy- id -i -/.ssh/id_rsa gitolite@gitserver 




This will ask you for the password to the gitolite account, and then set up public 
key access. This is essential for the install script, so check to make sure you can run 
a command without getting a password prompt: 

$ ssh gitolite@gitserver pwd 
/home/gitoiite 



Next, you clone Gitolite from the project' s main site and run the "easy install" 
script (the third argument is your name as you would like it to appear in the resulting 
gitolite- admin repository): 

$ git clone git://g ithub.com/sitaramc/gitolite 
$ cd gitolite/src 

$ ./g 卜 easy- install -q gitolite gitserver sitaram 
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And you' re done! Gitolite has now been installed on the server, and you now have 
a brand new repository called gitolite- admin in the home directory of your workstation. 
You administer your gitolite setup by making changes to this repository and pushing. 

That last command does produce a fair amount of output, which might be interesting 
to read. Also, the first time you run this, a new keypair is created; you will have to 
choose a passphrase or hit enter for none. Why a second keypair is needed, and 
how it is used, is explained in the "ssh troubleshooting" document that comes with 
Gitolite. (Hey the documentation has to be good for something!) 

Repos named gitolite- admin and testing are created on the server by default. If you 
wish to clone either of these locally (from an account that has SSH console access to 
the gitolite account via authorized — keys), type: 

$ git clone gitolite:gitolite-admin 
$ git clone gitolite:testing 



To clone these same repos from any other account: 



$ git clone gitolite@servername:gitolite-admin 
$ git clone gitolite@servername:testing 




4.8.2 Customising the Install 

While the default, quick, install works for most people, there are some ways to 
customise the install if you need to. If you omit the -q argument, you get a "verbose" 
mode install □ detailed information on what the install is doing at each step. The 
verbose mode also allows you to change certain server-side parameters, such as the 
location of the actual repositories, by editing an "rc" file that the server uses. This 
"rc" file is liberally commented so you should be able to make any changes you 
need quite easily, save it, and continue. This file also contains various settings that 
you can change to enable or disable some of gitolite' s advanced features. 

4.8.3 Config File and Access Control Rules 

Once the install is done, you switch to the gitolite- admin repository (placed in your 
HOME directory) and poke around to see what you got: 

$ cd -/gitolite- admin/ 
$ Is 

conf/ keydir/ 

$ find conf keydir -type f 

conf/gitolite.conf 

keydir/sitaram.pub 
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$ cat conf/gitolite.conf 
#gitolite conf 

# please see conf/exam pie. conf for details on syntax and features 
repo gitolite-admin 



RW+ = sitaram 

repo testing 

RW+ = ©all 



Notice that "sitaram" (the last argument in the g 卜 easy- install command you gave 
earlier) has read-write permissions on the gitolite-admin repository as well as a public 
key file of the same name. 

The config file syntax for gitolite is liberally documented in conf/example.conf, so 
we' II only mention some highlights here. 

You can group users or repos for convenience. The group names are just like 
macros; when defining them, it doesn' t even matter whether they are projects or 
users; that distinction is only made when you use the "macro" . 



@oss_repos 


= linux perl rakudo git gitolite 


◎secret— repos 


= fenestra pear 


◎admins 


= scott # Adams, not Chacon, sorry :) 


©interns 


= ashok # get the spelling right, Scott! 


©engineers 


= sitaram dilbert wally alice 


©staff = 


@admins ©engineers ©interns 



You can control permissions at the "ref" level. In the following example, interns 
can only push the "int" branch. Engineers can push any branch whose name starts 
with "eng-" ， and tags that start with "rc" followed by a digit. And the admins can 
do anything (including rewind) to any ref. 



repo @oss_repos 

RW int$ = ©interns 

RW eng- = ©engineers 

RW refs/tags/rc[0-9] = ©engineers 
RW+ = ©admins 



The expression after the RW or RW+ is a regular expression (regex) that the refname 
(ref) being pushed is matched against. So we call it a "ref ex" ！ Of course, a refex can 
be far more powerful than shown here, so don' t overdo it if you' re not comfortable 
with perl regexes. 
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Also, as you probably guessed, Gitolite prefixes refs/heads/ as a syntactic conve- 
nience if the refex does not begin with refs/. 

An important feature of the config file' s syntax is that all the rules for a repository 
need not be in one place. You can keep all the common stuff together, like the rules 
for all oss-repos shown above, then add specific rules for specific cases later on, like 
so: 

repo gitolite 

RW+ = sitaram 



That rule will just get added to the ruleset for the gitolite repository. 

At this point you might be wondering how the access control rules are actually 
applied, so let' s go over that briefly. 

There are two levels of access control in gitolite. The first is at the repository level; 
if you have read (or write) access to any ref in the repository, then you have read (or 
write) access to the repository. 

The second level, applicable only to "write" access, is by branch or tag within 
a repository. The username, the access being attempted ( W or +)， and the refname 
being updated are known. The access rules are checked in order of appearance in the 
config file, looking for a match for this combination (but remember that the refname is 
regex- matched, not merely string-matched). If a match is found, the push succeeds. 
A fallthrough results in access being denied. 

4.8.4 Advanced Access Control with "deny" rules 

So far, we' ve only seen permissions to be one or R， RW, or RW+. However, gitolite 
allows another permission: 一， standing for "deny" . This gives you a lot more power, 
at the expense of some complexity, because now fallthrough is not the only way for 
access to be denied, so the order of the rules now matters! 

Let us say, in the situation above, we want engineers to be able to rewind any 
branch except master and integ. Here' s how to do that: 

RW master integ = ©engineers 
- master integ = ©engineers 
RW+ = ©engineers 



Again, you simply follow the rules top down until you hit a match for your access 
mode, or a deny. Non-rewind push to master or integ is allowed by the first rule. A 
rewind push to those refs does not match the first rule, drops down to the second, 
and is therefore denied. Any push (rewind or non-rewind) to refs other than master 
or integ won' t match the first two rules anyway, and the third rule allows it. 
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4.8.5 Restricting pushes by files changed 

In addition to restricting what branches a user can push changes to, you can also 
restrict what files they are allowed to touch. For example, perhaps the Makefile (or 
some other program) is really not supposed to be changed by just anyone, because a 
lot of things depend on it or would break if the changes are not done just right. You 
can tell gitolite: 

repo foo 

RW = @junior_devs @senior_devs 



RW NAME/ = @senior_devs 

- NAME/Makefile = @junior_devs 
RW NAME/ = @junior_devs 




This powerful feature is documented in conf/example.conf. 

4.8.6 Personal Branches 

Gitolite also has a feature called "personal branches" (or rather, "personal 
branch namespace" ) that can be very useful in a corporate environment. 

A lot of code exchange in the git world happens by "please pull" requests. In a 
corporate environment, however, unauthenticated access is a no-no, and a developer 
workstation cannot do authentication, so you have to push to the central server and 
ask someone to pull from there. 

This would normally cause the same branch name clutter as in a centralised VCS, 
plus setting up permissions for this becomes a chore for the admin. 

Gitolite lets you define a "personal" or "scratch" namespace prefix for each 
developer (for example, refs/personal/<devname>/*); see the "personal branches" 
section in doc/3-faq-tips-etc.mkd for details. 

4.8.7 "Wildcard" repositories 

Gitolite allows you to specify repositories with wildcards (actually perl regexes), 
like, for example assignments/s[0-9][0-9]/a[0-9][0-9], to pick a random example. This is 
a very powerful feature, which has to be enabled by setting $GL_WlLDREPOS = 1； in 
the rc file. It allows you to assign a new permission mode ( "C，， ) which allows 
users to create repositories based on such wild cards, automatically assigns own- 
ership to the specific user who created it, allows him/her to hand out R and RW 
permissions to other users to collaborate, etc. This feature is documented in doc/4- 
wildcard - repositories.mkd. 

4.8.8 Other Features 

We' II round off this discussion with a sampling of other features, all of which, 
and many more, are described in great detail in the "faqs, tips, etc" and other 
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documents. 

Logging: Gitolite logs all successful accesses. If you were somewhat relaxed about 
giving people rewind permissions ( RW+) and some kid blew away "master" ， the log 
file is a life saver, in terms of easily and quickly finding the SHA that got hosed. 

Git outside normal PATH: One extremely useful convenience feature in gitolite is 
support for git installed outside the normal $PATH (this is more common than you 
think; some corporate environments or even some hosting providers refuse to install 
things system-wide and you end up putting them in your own directories). Normally, 
you are forced to make the client-side git aware of this non-standard location of the 
git binaries in some way. With gitolite, just choose a verbose install and set $GIT— PATH 
in the "rc，， files. No client-side changes are required after that :-) 

Access rights reporting: Another convenient feature is what happens when you try 
and just ssh to the server. Gitolite shows you what repos you have access to, and 
what that access may be. Here' s an example: 

hello sitaram, the gitolite version here is v1.5.4-19-ga3397d4 
the gitolite config gives you the following access: 

R anu-wsd 

R entrans 

R W git-notes 

R W gitolite 

R W gitolite- admin 

R indie— web— input 

R shreeli pi— converter 



Delegation: For really large installations, you can delegate responsibility for groups 
of repositories to various people and have them manage those pieces independently. 
This reduces the load on the main admin, and makes him less of a bottleneck. This 
feature has its own documentation file in the doc/ directory. 

Gitweb support: Gitolite supports gitweb in several ways. You can specify which 
repos are visible via gitweb. You can set the "owner" and "description" for 
gitweb from the gitolite config file. Gitweb has a mechanism for you to implement 
access control based on HTTP authentication, so you can make it use the "compiled" 
config file that gitolite produces, which means the same access control rules (for read 
access) apply for gitweb and gitolite. 

Mirroring: Gitolite can help you maintain multiple mirrors, and switch between 
them easily if the primary server goes down. 

4.9 Git 守 护进程 

对于 提供公 共的， 非授权 的只读 访问， 我们可 以抛弃 HTTP 协议， 改用 Git 自 己的协 
议， 这主要 是出于 性能和 速度的 考虑。 Git 协 议远比 HTTP 协议 高效， 因而访 问速度 也快， 
所以 它能节 省很多 用户的 时间。 
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重申 一下， 这 一点只 适用于 非授权 的只读 访问。 如果建 在防火 墙之外 的服务 器上， 那么它 
所提 供的服 务应该 只是那 些公开 的只读 项目。 如果是 在防火 墙之内 的服务 器上， 可用 于支撑 
大量 参与人 员或自 动系统 （用 于持续 集成或 编译的 主机） 只读 访问的 项目， 这 样可以 省去逐 

—配置 SSH 公钥的 麻烦。 

但不 管哪种 情形， Git 协议的 配置设 定都很 简单。 基 本上， 只 要以守 护进程 的形式 运行该 
命令 即可： 



git daemon -一 reuseaddr ― base-path=/opt/git/ /opt/git/ 



这里的 一reuseaddr 选项 表示在 重启服 务前， 不等之 前的连 接超时 就立即 重启。 而 一base- 
path 选 项则允 许克隆 项目时 不必给 出完整 路径。 最后 面的路 径告诉 Git 守护 进程允 许开放 
给用 户访问 的仓库 目录。 假 如有防 火墙， 则需 要为该 主机的 9418 端 口设置 为允许 通信。 

以守 护进程 的形式 运行该 进程的 方法有 很多， 但 主要还 得看用 的是什 么操作 系统。 在 
Ubuntu 主 机上， 可以用 Upstart 脚本 达成。 编辑该 文件： 



/etc/event.d/local-g it-daemon 



加 入以下 内容： 

start on startup 

stop on shutdown 

exec /usr/bin/git daemon \ 

― user=git ― group=git \ 

-- reuseaddr \ 

― base-path=/opt/git/ \ 

/opt/git/ 
respawn 



出 于安全 考虑， 强烈建 议用一 个对仓 库只有 读取权 限的用 户身份 来运行 该进程 一 只需要 

简单地 新建一 个名为 git-m 的用户 （ 译注： 新建用 户默认 对仓库 文件不 具备写 权限， 但这取 
决于仓 库目录 的权限 设定。 务 必确认 git-ro 对仓 库只 能读不 能写。 ）， 并用它 的身份 来启动 
进程。 这 里为了 简化， 后面 我们还 是用之 前运行 Gitosis 的用户 'git' 。 

这样 一来， 当你重 启计算 机时， Git 进程也 会自动 启动。 要是 进程意 外退出 或者被 杀掉， 
也 会自行 重启。 在 设置完 成后， 不重启 计算机 就启动 该守护 进程， 可以 运行： 



initctl start local-git-daemon 




而 在其他 操作系 统上， 可以用 xinetd, 或者 sysvinit 系统的 脚本， 或 者其他 类似的 脚本一 
只 要能让 那个命 令变为 守护进 程并可 监控。 
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接 下来， 我们必 须告诉 Gitosis 哪些 仓库允 许通过 Git 协议 进行匿 名只读 访问。 如 果每个 
仓库 都设有 各自的 段落， 可 以分别 指定是 否允许 Git 进程开 放给用 户匿名 读取。 比如 允许通 
过 Git 协 议访问 iphone-project, 可以把 下面两 行加到 gitosis.conf 文件的 末尾： 

[repo iphone-project] 
daemon = yes 



在 提交和 推送完 成后， 运 行中的 Git 守 护进程 就会响 应来自 9418 端 口对该 项目的 访问请 

求。 

如果 不考虑 Gitosis, 单 单起了 Git 守 护进程 的活， 就 必须到 每一个 允许匿 名只读 访问的 
仓库目 录内， 创建 一个特 殊名称 的空文 件作为 标志： 

$ cd /path/to/project. git 

$ touch git- daemon- export- ok 



该 文件的 存在， 表 明允许 Git 守护进 程开放 对该项 目的匿 名只读 访问。 
Gitosis 还能设 定哪些 项目允 许放在 GitWeb 上 显示。 先打开 GitWeb 的配 置文件 /etc/ 
gitweb.conf, 添加以 下四行 ： 

$projects-list = "/home/git/gitosis/projects.list"; 
$projectroot = "/home/git/repositories"; 
$export_ok = "git- daemon- export- ok"; 
@git— base — url — list = ('git://gitserver'); 



接 下来， 只要配 置各个 项目在 Gitosis 中的 gitweb 参数， 便能 达成是 否允许 GitWeb 用 
户 浏览该 项目。 比如， 要让 iphone-project 项目在 GitWeb 里 出现， 把 repo 的设 定改成 
下面的 样子： 

[repo iphone-project] 
daemon = yes 
gitweb = yes 



在 提交并 推送过 之后， GitWeb 就会 自动开 始显示 iphone-project 项目的 细节和 历史。 

4.10 Git 托 管服务 

如 果不想 经历自 己架设 Git 服 务器的 麻烦， 网络 上有几 个专业 的仓库 托管服 务可供 选择。 
这样做 有几大 优点： 托管 账户的 建立通 常比较 省时， 方便 项目的 启动， 而且不 涉及服 务器的 
维护和 监控。 即使 内部创 建并运 行着自 己的服 务器， 同时 为开源 项目提 供一个 公共托 管站点 
还是有 好处的 一 让开源 社区更 方便地 找到该 项目， 并给予 帮助。 
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目前， 可供 选择的 托管服 务数量 繁多， 各有 利弊。 在 Git 官方 wild 上的 Githosting 页面 
有 一个最 新的托 管服务 列表： 

http://git.or.cz/gitwiki/GitHosting 

由于 本书无 法全部 一一 介绍， 而本人 （译注 ： 指本 书作者 Scott Chacon。 ） 刚好 在其中 
一 家公司 工作， 所以 接下来 我们将 会介绍 如何在 GitHub 上建立 新账户 并启动 项目。 至于其 
他 托管服 务大体 也是这 么一个 过程， 基本的 想法都 是差不 多的。 

GitHub 是 目前为 止最大 的开源 Git 托管 服务， 并且还 是少数 同时提 供公共 代码和 私有代 
码托 管服务 的站点 之一， 所以 你可以 在上面 同时保 存开源 和商业 代码。 事 实上， 本书 就是放 
在 GitHub 上 合作编 著的。 （译注 ： 本书的 翻译也 是放在 GitHub 上 广泛协 作的。 ） 

4.10.1 GitHub 

GitHub 和大 多数的 代码托 管站点 在处理 项目命 名空间 的方式 上略有 不同。 GitHub 的设 
计更 侧重于 用户， 而不是 完全基 于项目 。也就 是说， 如 果我在 GitHub 上 托管一 个名为 grit 
的项目 的活， 它 的地址 不会是 github.com/grit, 而是 按在用 户底下 github.com/shacon/grit 
(译注 ： 本 书作者 Scott Chacon 在 GitHub 上的用 户名是 sh acon 。 ） 。 不 存在所 谓某个 
项目 的官方 版本， 所 以假如 第一作 者放弃 了某个 项目， 它 可以无 缝转移 到其它 用户的 名下。 

GitHub 同时 也是一 个向使 用私有 仓库的 用户收 取费用 的商业 公司， 但任何 人都可 以方便 
快 捷地申 请到一 个免费 账户， 并 在上面 托管数 量不限 的开源 项目。 接下 来我们 快速介 绍一下 
GitHub 的基本 使用。 

4.10.2 建立 新账户 

首先) '主 册一个 免费 账户。 访 1司 Pricing and Signup 页面 http://github.com/plans 并,^ ；击 
Free acount 里的 Sign Up 按钮 （ 见图 4-2 ) , 进 入注册 页面。 



eithub — (^) 

OtooHCooMc an 一國— 



Mom* PiMnj niunim (kporitata 



Choose the plan that's right for you. 

0p«n Sourc* 



LMiinited ■---「"—■：;.:;，■.::-'_'，」 
UnllmttMl PuWc Cdtaboram '2 
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图 4.2: GitHub 服务简 介页面 

选 择一个 系统中 尚未使 用的用 户名， 提供一 个与之 相关联 的电邮 地址， 并输 入密码 （见图 
4-3 ) ： 

如果 方便， 现在就 可以提 供你的 SSH 公钥。 我们在 前文的 "小型 安装" 一 节介绍 过生成 
新 公钥的 方法。 把新生 成的公 钥复制 粘贴到 SSH Public Key 文 本框中 即可。 要是对 生成公 
钥的步 骤不太 清楚， 也可 以点击 "explain ssh keys" 链接， 会显示 各个主 流操作 系统上 
完成该 步骤的 介绍。 点击 "I agree, sign me up" 按钮完 成用户 注册， 并 转到该 用户的 
dashboard 页面 ( 见图 4-4 ) ： 

接 下来就 可以建 立新仓 库了。 



4.10.3 建立 新仓库 

点击用 户面板 上仓库 旁边的 "create a new one" 链接， 显示 Create a New Repository 
的表单 （见图 4-5) ： 
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Sign up 

Ummm 
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图 4.3: GitHub 用户注 册表单 

eithub 
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图 4.4: GitHub 的用 户面板 



Create a New Repository 
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图 4.5: 在 GitHub 上建立 新仓库 



当然， 项目 名称是 必不可 少的， 此 外也可 以适当 描述一 下项目 的情况 或者给 出官方 站点的 
地址。 然 后点击 "Create Repository" 按钮， 新仓库 就建立 起来了 （ 见图 4-6 ) ： 
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图 4.6: GitHub 上 各个项 目的概 要信息 

由于尚 未提交 代码， 点 击项目 地址后 GitHub 会显 示一个 简要的 指南， 告诉 你如何 新建一 
个项目 并推送 上来， 如 何从现 有项目 推送， 以 及如何 从一个 公共的 Subversion 仓库 导入项 
目 （见图 4-7 ) ： 
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Global setup: 

Oownlood and instoll Git 

git config --global user. email test#gi thub . can 

Next steps: 

akdir iphonc^roject 

cd iphone_proje<t 

git init 

tou<h READMC 

git add README 

git coMit -矚 'first com"' 

git remote odd origin 9it9gtttwb.co0i:testin9user/iphone_project.git 
git push origin Master 

Existing Gil Repo? 

cd txi st i ng_gi t_ripo 

git remote odd origin git9github.com:testinguser/iphone_project.git 
git push origin moster 

Impohing a SVN Repo? 



When you're done: 



图 4.7: 新仓 库指南 

该指 南和本 书前文 介绍的 类似， 对 于新的 项目， 需 要先在 本地初 始化为 Git 项目， 添加要 
管理的 文件并 作首次 提交： 



$ git init 
$ git add . 

$ git commit -m 'initial commit' 



然后 在这个 本地仓 库内把 GitHub 添加 为远程 仓库， 并推送 master 分支 上来: 



$ git remote add origin git@github.com:testinguser/iphone_project.git 
$ git push origin master 



现在该 项目就 托管在 GitHub 上了。 你可以 把它的 URL 分 享给每 位对此 项目感 兴趣的 
人。 本例的 URL 是 。 而在项 目页面 的摘要 部分， 你 会发现 有两个 Git URL 地址 （见图 
4-8 ) ： 

testinguser / iphone_project " ed«) ( • unwaich ) 

Dcscr ption iphonc pro.cct for our met) Ic grojp cu - 

Homepage ： Click to edit edit 

Public Ctone URL: git 7/github cofnAasting user/iphone project.git g 
Your Clone URL: git® github.com nesting userApfXMie projectgil £ 



图 4.8: 项目 摘要中 的公共 URL 和私有 URL 

Public Clone URL 是一 个公 开的， 只读的 Git URL, 任何人 都可以 通过它 克隆该 项目。 
可以 随意散 播这个 URL, 比如 发布到 个人网 站之类 的地方 等等。 

Your Clone URL 是一 个基于 SSH 协 议的可 读可写 URL, 只有 使用与 上传的 SSH 公钥 
对 应的密 钥来连 接时， 才能通 过它进 行读写 操作。 其他用 户访问 该项目 页面时 只能看 到之前 
那个 公共的 URL, 看不 到这个 私有的 URL。 
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4.10 节 Git 托 管服务 



4.10.4 从 Subversion 导 入项目 

如果 想把某 个公共 Subversion 项 目导入 Git, GitHub 可以 帮忙。 在指南 的最后 有一个 
指 向导入 Subversion 页面的 链接。 点击 它会看 到一个 表单， 包 含有关 导入流 程的信 息以及 
—个 用来粘 贴公共 Subversion 项目 连接的 文本框 （ 见图 4-9 ) ： 



Import e Subversion Repository 

Rt*d Mors ProcMdlng 

• nwmpoWprooowoodMa— — 6 mtitftt Ion long w ，d>]W<Wpooang on Ihowrf you wpo«loi>- Th^hw 
MOW r.j-sr rwwflW WpartyawwM 

SVHWtpOWwyUHLq) 



图 4.9: Subversion 导 入界面 

如 果项目 很大， 采用 非标准 结构， 或 者是私 有的， 那就 无法借 助该工 具实现 导入。 到第 7 
章 ， 我们会 介绍如 何手工 导入复 杂工程 的具体 方法。 



4.10.5 添 加协作 开发者 

现在把 团队里 的其他 人也加 进来。 如果 john, josie 和 jessica 都在 GitHub 注 册了账 
户， 要赋予 他们对 该仓库 的推送 权限， 可 以把他 们加为 项目协 作者。 这 样他们 就可以 通过各 
自 的 公钥访 问我的 这个仓 库了。 

点击项 目页面 上方的 "edit" 按 钮或者 顶部的 Admin 标签， 进 入该项 目的管 理页面 （见 
图 4-10 ) ： 



Wstinguser / iphon*. project 

PMbfc Pan* UW^ 9»jyw6comftw*nuwi<ptWB»jwtict9« B 




amuoPtg*. OwM* PnHtcl P^t 






Repository Collaborators 




AMwoiMreeMomor 





图 4.10: GitHub 的 项目管 理页面 

为了 给另一 个用户 添加项 目的写 权限， 点击 "Add another collaborator" 链接， 出现 
一 个用于 输入用 户名的 表单。 在 输入的 同时， 它会自 动跳出 一个符 合条件 的候选 名单。 找到 
正确 用户名 之后， 点 Add 按钮， 把该 用户设 为项目 协作者 （见图 4-11 ) ： 

添加完 协作者 之后， 就 可以在 Repository Collaborators 区域看 到他们 的名单 （见图 
4-12 ) ： 

如果要 取消某 人的访 问权， 点击 "revoke" 即可 取消他 的推送 权限。 对于 将来的 项目， 
你 可以从 现有项 目 复制 协作者 名单， 或者直 接借用 协作者 群组。 

4.10.6 项 目页面 

在推 送或从 Subversion 导 入项目 之后， 你会看 到一个 类似图 4-13 的项目 主页： 
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Repository Coll&boralori 



「' w 



图 4.11: 为项 目添加 协作者 



Repository Collaborators 



Q schaco 


n revoke 


duncan 


parkes revoke 


spearcc 


i rsvoks 




J (Add) or done 




图 4.12: 项 目协作 者名单 


？ ithub 

o - , 


Hem* PrWnB md Slqmip f^mnonm Bug loqm 

一 tmtim» 


Souro* 


tMaoA(l) Oowraoadi |0) VW»(1) (kipfw 







DWHW VhenapRiMla'ag'niBMeeraup 








phone— project f 










― Iirf*.,llM S 4tf% •(§ 


tnitUl cavtt [kmcsx] 




Initial cowlt [Kfwcwi) 




tHttUt CMMI [Kt«MA] 




tn"t,l caiMt 【Kt*co»l 


- iCftVtwC«Mr«ll«r.«t» J «an a|B 




' "tt_rr«fU.M*> 1 — ， 


tnttlal cwrtt [Kftacan] 


- s 4tt* m» 


tnttial cowtt 【KT*ca»l 



图 4.13: GitHub 上的项 目主页 

别 人访问 你的项 目时看 到的就 是这个 页面。 它有若 干导航 标签， Commits 标签用 于显示 
提交 历史， 最新 的提交 位于最 上方， 这和 git log 命令 的输出 类似。 Network 标签展 示所有 
派生 了该项 目并做 出贡献 的用户 的关系 图谱。 Downloads 标签 允许你 上传项 目的二 进制文 
件， 提供下 载该项 目各个 版本的 tar/zip 包。 Wiki 标签 提供了 一个用 于撰写 文档或 其他项 
目相关 信息的 wild 站点。 Graphs 标 签包含 了一些 可视化 的项目 信息与 数据。 默认 打开的 
Source 标签 页面， 则列出 了该项 目的目 录结构 和概要 信息， 并在 下方自 动展示 README 
文件 的内容 （ 如果该 文件存 在的活 ） ， 此外还 会显示 最近一 次提交 的相关 信息。 

4.10.7 派 生项目 

如果 要为一 个自 己没有 推送权 限的项 目贡献 代码， GitHub 鼓励使 用派生 （fork) 。 到那 
个感 兴趣的 项目主 页上， 点 击页面 上方的 "fork" 按钮， GitHub 就 会为你 复制一 份该项 
目 的 副本到 你的仓 库中， 这 样你就 可以向 自 己的这 个副本 推送数 据了。 
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4.11 节 小结 



采取 这种办 法的好 处是， 项目 拥有者 不必忙 于应付 赋予他 人推送 权限的 工作。 随便 谁都可 
以 通过派 生得到 一个项 目副本 并在其 中展开 工作， 事后只 需要项 目维护 者将这 些副本 仓库加 
为远程 仓库， 然后 提取更 新合并 即可。 

要派生 一个 项目， 到原 始项目 的页面 （本 例中是 mojombo/chronic) 点击 "fork" 按 
钮 （见图 4-14) ： 



1 

」】 


3 














11. MM 


rami nfct«m«[Md»iHt*tmn— if»iw*7» 



图 4.14: 点击 "fork" 按 钮获得 任意项 目的可 写副本 

几秒钟 之后， 你将进 入新建 的项目 页面， 会显 示该项 目派生 自哪一 个项目 （见图 4- 
15) ： 

schacon / chronic C> «m ) c ' unwaich .' 

Fork of mc^ombo/chronic 

Ducr^ition: Chronic is a puro Ruby natural language dato parser, odit 
Homepage: http7/chronic. rubyforge.org odit 

Public Clone URL: gity/gittiub.oom/schacon/chronic.git Q 
Your Clone URL: gttOgittiub .com :schacorVchronic.git £J 

图 4.15: 派 生后得 到的项 目副本 



4.10.8 GitHub 小结 

关于 GitHub 就先 介绍这 么多， 能够 快速达 成这些 事情非 常重要 （译注 ： 门 槛的降 低和完 
成基 本任务 的简单 高效， 对于 推动开 源项目 的协作 发展有 着举足 轻重的 意义。 ） 。 短 短几分 
钟内， 你就 能创建 一个新 账户， 添加一 个项目 并开始 推送。 如果项 目是开 源的， 整个 庞大的 
开发 者社区 都可以 立即访 问它， 提 供各式 各样的 帮助和 贡献。 最 起码， 这也 是一种 Git 新手 
立即体 验尝试 Git 的 捷径。 

4.11 小结 

我们 讨论并 介绍了 一些建 立远程 Git 仓库的 方法， 接下 来你可 以通过 这些仓 库同他 人分享 
或 合作。 

运行 自己的 服务器 意味着 更多的 控制权 以及在 防火墙 内部操 作的可 能性， 当 然这样 的服务 
器通 常需要 投入一 定的时 间精力 来架设 维护。 如 果直接 托管， 虽然 能免去 这部分 工作， 但有 
时出于 安全或 版权的 考虑， 有些公 司禁止 将商业 代码托 管到第 三方服 务商。 

所以 究竟采 取哪种 方案， 并不是 个难以 取舍的 问题， 或者 其一， 或 者相互 配合， 哪 种合适 
就用 哪种。 
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为了便 于项目 中的所 有开发 者分享 代码， 我们准 备好了 一台服 务器存 放远程 Git 仓库。 经 
过前面 几章的 学习， 我们已 经学会 了一些 基本的 本地工 作流程 中所需 用到的 命令。 接 下来， 
我 们要学 习下如 何利用 Git 来组 织和完 成分布 式工作 流程。 

特 别是， 当 作为项 目贡献 者时， 我们该 怎么做 才能方 便维护 者采纳 更新； 或 者作为 项目维 
护 者时， 又该 怎样有 效管理 大量贡 献者的 提交。 



5.1 分 布式工 作流程 

同 传统的 集中式 版本控 制系统 （ CVCS ) 不同， 开发者 之间的 协作方 式因着 Git 的 分布式 
特性而 变得更 为灵活 多样。 在集 中式系 统上， 每 个开发 者就像 是连接 在集线 器上的 节点， 彼 
此的 工作方 式大体 相像。 而在 Git 网 络中， 每个 开发者 同时扮 演着节 点和集 线器的 角色， 这 
就 是说， 每一个 开发者 都可以 将自己 的代码 贡献到 另外一 个开发 者的仓 库中， 或者建 立自己 
的公共 仓库， 让 其他开 发者基 于自己 的工作 开始， 为自 己的仓 库贡献 代码。 于是， Git 的分 
布式 协作便 可以衍 生出种 种不同 的工作 流程， 我 会在接 下来的 章节介 绍几种 常见的 应用方 
式， 并分别 讨论各 自的优 缺点。 你可 以选择 其中的 一种， 或 者结合 起来， 应用 到你自 己的项 
目中。 



5.1.1 集中式 工作流 

通常， 集 中式工 作流程 使用的 都是单 点协作 模型。 一个存 放代码 仓库的 中心服 务器， 可以 
接 受所有 开发者 提交的 代码。 所有 的开发 者都是 普通的 节点， 作为中 心集线 器的消 费者， 平 
时的工 作就是 和中心 仓库同 步数据 （ 见图 5-1 ) 。 



developer 




shared 
repository 



developer 




developer 



图 5.1: 集中式 工作流 
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如 果两个 开发者 从中心 仓库克 隆代码 下来， 同时作 了一些 修订， 那么 只有第 一个开 发者可 
以 顺利地 把数据 推送到 共享服 务器。 第 二个开 发者在 提交他 的修订 之前， 必须 先下载 合并服 
务 器上的 数据， 解决 冲突之 后才能 推送数 据到共 享服务 器上。 在 Git 中 这么用 也决无 问题， 
这 就好比 是在用 Subversion ( 或其他 CVCS ) —样， 可以 很好地 工作。 

如果 你的团 队不是 很大， 或者 大家都 已经习 惯了使 用集中 式工作 流程， 完全 可以采 用这种 
简单的 模式。 只需 要配置 好一台 中心服 务器， 并 给每个 人推送 数据的 权限， 就 可以开 展工作 
了。 但如果 提交代 码时有 冲突， Git 根本就 不会让 用户覆 盖他人 代码， 它直接 驳回第 二个人 
的提交 操作。 这 就等于 告诉提 交者， 你所作 的修订 无法通 过快近 （ fast-forward ) 来 合并， 
你 必须先 拉取最 新数据 下来， 手 工解决 冲突合 并后， 才能 继续推 送新的 提交。 绝大多 数人都 
熟悉和 了解这 种模式 的工作 方式， 所 以使用 也非常 广泛。 



5.1.2 集成 管理员 工作流 

由于 Git 允许 使用多 个远程 仓库， 开 发者便 可以建 立自己 的公共 仓库， 往里 面写数 据并共 
享给 他人， 而同 时又可 以从别 人的仓 库中提 取他们 的更新 过来。 这种情 形通常 都会有 个代表 
着 官方发 布的项 目仓库 （blessed repository ) , 开发者 们由此 仓库克 隆出一 个自己 的公共 
仓库 （developer public) , 然 后将自 己的提 交推送 上去， 请求 官方仓 库的维 护者拉 取更新 
合 并到主 项目。 维 护者在 自己的 本地也 有个克 隆仓库 （ integration manager) , 他 可以将 
你的 公共仓 库作为 远程仓 库添加 进来， 经过测 试无误 后合并 到主干 分支， 然后 再推送 到官方 
仓库。 工 作流程 看起来 就像图 5-2 所示： 

1. 项 目维护 者可以 推送数 据到公 共仓库 blessed repository. 

2. 贡献者 克隆此 仓库， 修订或 编写新 代码。 

3. 贡献者 推送数 据到自 己的公 共仓库 developer public. 

4. 贡献者 给维护 者发送 邮件， 请求拉 取自己 的最新 修订。 

5. 维护者 在自己 本地的 integration manger 仓 库中， 将贡 献者的 仓库加 为远程 仓库， 
合并更 新并做 测试。 

6. 维 护者将 合并后 的更新 推送到 主仓库 blessed repository. 




图 5.2: 集成 管理员 工作流 



在 GitHub 网站 上使用 得最多 的就是 这种工 作流。 人们可 以复制 （fork 亦即 克隆） 某个 
项 目到自 己的列 表中， 成 为自己 的公共 仓库。 随 后将自 己的更 新提交 到这个 仓库， 所 有人都 
可以 看到你 的每次 更新。 这么做 最主要 的优点 在于， 你可以 按照自 己的节 奏继续 工作， 而不 
必等待 维护者 处理你 提交的 更新； 而维护 者也可 以按照 自己的 节奏， 任 何时候 都可以 过来处 
理接 纳你的 贡献。 
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5.2 节 为项目 作贡献 



5.1.3 司令官 与副官 工作流 

这其 实是上 一种工 作流的 变体。 一般 超大型 的项目 才会用 到这样 的工作 方式， 像是 拥有数 
百 协作开 发者的 Linux 内核项 目就是 如此。 各个 集成管 理员分 别负责 集成项 目中的 特定部 
分， 所以称 为副官 （lieutenant) 。 而所有 这些集 成管理 员头上 还有一 位负责 统筹的 总集成 
管 理员， 称为 司令官 （ dictator ) 。 司令官 维护的 仓库用 于提供 所有协 作者拉 取最新 集成的 
项目 代码。 整个流 程看起 来如图 5-3 所示： 

1. 一般的 开发者 在自己 的特性 分支上 工作， 并不 定期地 根据主 干分支 （dictator 上的 
master ) 衍合。 

2. 副官 （lieutenant) 将普 通开发 者的特 性分支 合并到 自己的 master 分 支中。 

3. 司令官 （ dictator ) 将所有 副官的 master 分 支并入 自己的 master 分支。 

4. 司令官 ( dictator ) 将集 成后的 master 分支推 送至! | 共 享仓库 blessed repository 中， 
以 便所有 其他开 发者以 此为基 础进行 衍合。 




图 5.3: 司令官 与副官 工作流 



这种 工作流 程并不 常用， 只 有当项 目极为 庞杂， 或者 需要多 级别管 理时， 才会体 现出优 
势。 利 用这种 方式， 项目总 负责人 （即司 令官） 可 以把大 量分散 的集成 工作委 托给不 同的小 
组负责 人分别 处理， 最后 再统筹 起来， 如此各 人的职 责清晰 明确， 也不 易出错 （译注 ： 此乃 
分 而治之 ） 。 

以上介 绍的是 常见的 分布式 系统可 以应用 的工作 流程， 当然 不止于 Git。 在 实际的 开发工 
作中， 你可能 会遇到 各种为 了满足 特定需 求而有 所变化 的工作 方式。 我 想现在 你应该 已经清 
楚， 接下来 自己需 要用哪 种方式 开展工 作了。 下节 我还会 再举些 例子， 看看各 式工作 流中的 
每 个角色 具体应 该如何 操作。 



5.2 为项目 作贡献 

接 下来， 我们来 学习一 下作为 项目贡 献者， 会有哪 些常见 的工作 模式。 

不过 要说清 楚整个 协作过 程真的 很难， Git 如此 灵活， 人们的 协作方 式便可 以各式 各样， 
没有固 定不变 的范式 可循， 而 每个项 目的具 体情况 又多少 会有些 不同， 比如 说参与 者的规 
模， 所选择 的工作 流程， 每个人 的提交 权限， 以及 Git 以 外贡献 等等， 都会影 响到具 体操作 
的 细节。 
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首当其 冲的是 参与者 规模。 项目中 有多少 开发者 是经常 提交代 码的？ 经常 又是多 久呢？ 大 
多数 两至三 人的小 团队， 一天 大约只 有几次 提交， 如果 不是什 么热门 项目的 活就更 少了。 可 
要是 在大公 司里， 或 者大项 目中， 参 与者可 以多到 上千， 每天都 会有十 几个上 百个补 丁提交 
上来。 这种 差异带 来的影 晌是显 著的， 越 是多的 人参与 进来， 就越难 保证每 次合并 正确无 
误。 你正在 工作的 代码， 可能会 因为合 并进来 其他人 的更新 而变得 过时， 甚 至受创 无法运 
行。 而已 经提交 上去的 更新， 也 可能在 等着审 核合并 的过程 中变得 过时。 那么， 我们 该怎样 
做才能 确保代 码是最 新的， 提交的 补丁也 是可用 的呢？ 

接下来 便是项 目所采 用的工 作流。 是集中 式的， 每个开 发者都 具有等 同的写 权限？ 项目是 

否 有专人 负责检 查所有 补丁？ 是不 是所有 补丁都 做过同 行复阅 （ peer-review ) 再通 过审核 
的？ 你 是否参 与审核 过程？ 如果使 用副官 系统， 那你 是不是 限定于 只能向 此副官 提交？ 

还有你 的提交 权限。 有 或没有 向主项 目提交 更新的 权限， 结 果完全 不同， 直 接决定 最终采 
用怎 样的工 作流。 如果 不能直 接提交 更新， 那该如 何贡献 自己的 代码呢 ？是不 是该有 个什么 
策略？ 你 每次贡 献代码 会有多 少量？ 提交频 率呢？ 

所有 以上这 些问题 都会或 多或少 影响到 最终采 用的工 作流。 接 下来， 我会在 一系列 由简入 
繁的 具体用 例中， 逐一 阐述。 此 后在实 践时， 应该可 以借鉴 这里的 例子， 略作 调整， 以满足 
实 际需要 构建自 己的工 作流。 

5.2.1 提 交指南 

开始 分析特 定用例 之前， 先来 了解下 如何撰 写提交 说明。 一份好 的提交 指南可 以帮助 
协 作者更 轻松更 有效地 配合。 Git 项目本 身就提 供了一 份文档 （Git 项目 源代码 目录中 
Documentation/SubmittingPatches ) , 列数 了大量 提示， 从如何 编撰提 交说明 到提交 补丁， 不 
—而足 0 

首先， 请不要 在更新 中提交 多余的 白字符 （whitespace) 。 Git 有 种检查 此类问 题的方 
法， 在提交 之前， 先运行 git diff —check, 会 把可能 的多余 白字符 修正列 出来。 下 面的示 
例， 我已 经把终 端中显 示为红 色的白 字符用 X 替 换掉： 

$ git diff —check 

lib/simplegit.rb:5: trailing whitespace. 

+ @git_dir = Fi le. expand -path (git_dir) XX 

lib/simplegit.rb:7: trailing whitespace. 

+ xxxxxxxxxxx 

lib/simplegit.rb:26: trailing whitespace. 
+ def command (git_cmd)XXXX 



这样在 提交之 前你就 可以看 到这类 问题， 及时 解决以 免困扰 其他开 发者。 
接 下来， 请将每 次提交 限定于 完成一 次逻辑 功能。 并 且可能 的话， 适 当地分 解为多 次小更 
新， 以便每 次小型 提交都 更易于 理解。 请不 要在周 末穷追 猛打一 次性解 决五个 问题， 而最后 
拖到 周一再 提交。 就算 是这样 也请尽 可能利 用暂存 区域， 将之前 的改动 分解为 每次修 复一个 

问题， 再分 别提交 和加注 说明。 如果针 对两个 问题改 动的是 同一个 文件， 可以 试试看 git add 
-patch 的方 式将部 分内容 置入暂 存区域 （ 我们会 在第六 章再详 细介绍 ） 。 无 论是五 次小提 
交 还是混 杂在一 起的大 提交， 最 终分支 末端的 项目快 照应该 还是一 样的， 但分 解开来 之后， 
更便 于其他 开发者 复阅。 这 么做也 方便自 己将来 取消某 个特定 问题的 修复。 我 们将在 第六章 
介绍 一些重 写提交 历史， 同暂 存区域 交互的 技巧和 工具， 以便 最终得 到一个 干净有 意义， 且 
易 于理解 的提交 历史。 
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最 后需要 谨记的 是提交 说明的 撰写。 写 得好可 以让大 家协作 起来更 轻松。 一般 来说， 提交 
说明最 好限制 在一行 以内， 50 个字符 以下， 简明扼 要地描 述更新 内容， 空开一 行后， 再展 
开详细 注解。 Git 项 目本身 需要开 发者撰 写详尽 注解， 包 括本次 修订的 因由， 以及前 后不同 
实现 之间的 比较， 我们 也该借 鉴这种 做法。 另外， 提交说 明应该 用祈使 现在式 语态， 比如， 
不 要说成 "I added tests for" 或 "Adding tests for" 而 应该用 "Add tests for" 。 下 
面 是来自 tpope.net 的 Tim Pope 原创的 提交说 明格式 模版， 供 参考： 



本次更 新的简 要描述 （ 50 个字 符以内 ） 

如果 必要， 此处展 开详尽 阐述。 段 落宽度 限定在 72 个字符 以内。 
某些情 况下， 第 一行的 简要描 述将用 作邮件 标题， 其余 部分作 为邮件 正文。 
其 间的空 行是必 要的， 以区 分两者 （当然 没有正 文另当 别论） 。 
如 果并在 一起， rebase 这样的 工具就 可能会 迷惑。 

另 起空行 Jt, 再进 一步补 充其他 说明。 

-可 以使用 这样的 条目列 举式。 

- 一般以 单个空 格紧跟 短划线 或者星 号作为 每项条 目的起 始符。 每个条 目间用 一空行 隔开。 
不 过这里 按自己 项目的 约定， 可 以略作 变化。 



如 果你的 提交说 明都用 这样的 格式来 书写， 好多 事情就 可以变 得十分 简单。 Git 项 目本身 
就是 这样要 求的， 我 强烈建 议你到 Git 项 目仓库 下运行 git log -no-merges 看看， 所 有提交 
历史的 说明是 怎样撰 写的。 （译注 ： 如果现 在还没 有克隆 git 项目源 代码， 是时候 git done 
git://git.kernel.org/pub/scm/g it/git. git 了。 ) 

为简单 起见， 在 接下来 的例子 （ 及 本书随 后的所 有演示 ） 中， 我 都不会 用这种 格式， 而使 

用 - m 选 项提交 git commit. 不过 请还是 按照我 之前讲 的做， 别学 我这里 偷懒的 方式。 

5.2.2 私 有的小 型团队 

我们从 最简单 的情况 开始， 一 个私有 项目， 与 你一起 协作的 还有另 外一到 两位开 发者。 这 
里说 私有， 是指源 代码不 公开， 其他人 无法访 问项目 仓库。 而你 和其他 开发者 则都具 有推送 
数据到 仓库的 权限。 

这种情 况下， 你们 可以用 Subversion 或 其他集 中式版 本控制 系统类 似的工 作流来 协作。 
你 仍然可 以得到 Git 带来 的其他 好处： 离线 提交， 快 速分支 与合并 等等， 但工 作流程 还是差 
不 多的。 主 要区别 在于， 合并 操作发 生在客 户端而 非服务 器上。 让 我们来 看看， 两个 开发者 
一起使 用同一 个共享 仓库， 会 发生些 什么。 第一 个人， john, 克隆了 仓库， 作了些 更新， 
在本地 提交。 （下面 的例子 中省略 了常规 提示， 用… 代替 以节约 版面。 ） 

# John's Machine 

$ git clone john@githost:simplegit.git 

Initialized empty Git repository in /home/john/simplegit/.git/ 
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$ cd simplegit/ 

$ vim lib/simplegit.rb 

$ git commit -am 'removed invalid default value' 
[master 738ee87] removed invalid default value 
1 files changed, 1 insertions( + ), 1 deletions ( — ) 



第 二个开 发者， jessica, —样这 么做： 克隆 仓库， 提交 更新: 

# Jessica's Machine 

$ git clone jessica@githost:simplegit.git 

Initialized empty Git repository in /home/jessica/simplegit/.git/ 

$ cd simplegit/ 
$ vim TODO 

$ git commit -am 'add reset task' 
[master fbff5bc] add reset task 
1 files changed, 1 insertions( + ), 0 deletions ( — ) 



现在， jessica 将 她的工 作推送 到服务 器上: 

# Jessica's Machine 

$ git push origin master 

To jessica@githost:simplegit.git 

1edee6b..fbff5bc master -> master 



John 也 尝试推 送自己 的工作 上去: 



# John's Machine 




$ git push origin master 




To john@githost:simplegit.git 




！ [rejected] master -> master ( nc 


>n-fast forward ) 


error: failed to push some refs to 'johr 


i@githost:si mplegit.gif 



John 的推送 操作被 驳回， 因为 jessica 已经推 送了新 的数据 上去。 请 注意， 特别 是你用 
惯了 Subversion 的话， 这 里其实 修改的 是两个 文件， 而不 是同一 个文 件的同 一个 地方。 
Subversion 会在服 务器端 自动合 并提交 上来的 更新， 而 Git 则 必须先 在本地 合并后 才能推 
送。 于是， john 不得 不先把 jessica 的 更新拉 下来： 
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$ git fetch origin 




From john@githost:simplegit 




+ 049d078...fbff5bc master - 


-> origin/ master 



此刻， john 的 本地仓 库如图 5-4 所示: 



master 




origin/master 



图 5.4: John 的仓 库历史 

虽然 John 下载了 Jessica 推送 到服务 器的最 近更新 ( fbff5 ) , 但目 前只是 origin/master 
指针指 向它， 而当 前的本 地分支 master 仍然指 向自己 的更新 （ 738ee ) , 所 以需要 先把她 
的提 交合并 过来， 才能继 续推送 数据： 

$ git merge origin/ master 
Merge made by recursive. 
TODO I 1 + 

1 files changed, 1 insertions( + ), 0 deletions (-) 

还好， 合并过 程非常 顺利， 没有 冲突， 现在 john 的 提交历 史如图 5-5 所示： 
现在， john 应该再 测试一 下代码 是否仍 然正常 工作， 然 后将合 并结果 （ 72bbc ) 推送到 
服务 器上： 



$ git push origin master 

To john@githost:simplegit.git 

fbff5bc..72bbc59 master — > master 



最终， john 的提 交历史 变为图 5-6 所示: 
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bff5 ) 



origin/master 



图 5.5: 合并 origin/master 后 john 的仓 库历史 





- { 4b078 ) ^~ ^ 1 edee^^— ^7 3 8ee ^^- 72bbc ) 



fbff5 



origin/master 



图 5.6: 推送后 john 的仓 库历史 

而 在这段 时间， jessica 已 经开始 在另一 个特性 分支工 作了。 她 创建了 is SU e54 并提 交了: 
次 更新。 她还没 有下载 john 提交 的合并 结果， 所以 提交历 史如图 5-7 所示： 



一- - { 4b078 ) ~^~ ^ ledee"^-< fbff5 8149a ^-^ 23ac6 ^-^ 4af42 ) 



1 



origin/master 



图 5.7: Jessica 的提 交历史 
Jessica 想要 先和服 务器上 的数据 同步， 所以 先下载 数据： 



# Jessica's Machine 
$ git fetch origin 



From jessica@githost:simplegit 
fbff5bc..72bbc59 master -> origin/ master 



于是 jessica 的 本地仓 库历史 多出了 john 的两 次提交 （ 738ee 和 72bbc ) , 如图 5-8 所 
示： 

此时， jessica 在特 性分支 上的工 作已经 完成， 但她 想在推 送数据 之前， 先 确认下 要并进 
来 的数据 究竟是 什么， 于 是运行 git log 查看： 

114 



Scott Chacon Pro Git 



5.2 节 为项目 作贡献 




23ac6〕 ^~ ^ 4af42 ) 



图 5.8: 获取 john 的更 新之后 jessica 的提 交历史 



$ git log ― no-merges origin/ master A issue54 
commit 738ee872852dfaa9d6634e0dea7a3240401 93016 
Author: John Smith <jsmith@example.com> 
Date: Fri May 29 16:01:27 2009 - 0700 



removed invalid default value 



现在， jessica 可 以将特 性分支 上的工 作并到 master 分支， 然后 再并入 john 的工作 
(origin/master) 到 自己的 master 分支， 最 后再推 送回服 务器。 当然， 得先切 回主分 支才能 
集 成所有 数据： 



$ git checkout master 
Switched to branch "master" 

Your branch is behind 'origin/ master' by 2 commits, and can be fast-forwarded. 



要合并 origin/master 或 i SSue 54 分支， 谁 先谁后 都没有 关系， 因为 它们都 在上游 （up- 
stream ) ( 译注： 想像 分叉的 更新像 是汇流 成河的 源头， 所 以上游 upstream 是指 最新的 
提交 ） ， 所 以无所 谓先后 顺序， 最 终合并 后的内 容快照 都是一 样的， 而 仅是提 交历史 看起来 
会有 些先后 差别。 jessica 选择 先合并 is SU e54 : 



$ git merge issue54 
Updating fbff5bc..4af4298 
Fast forward 

README I 1 + 

lib/simplegit.rb I 6 +++++- 

2 files changed, 6 insertions( + ), 1 deletions ( — ) 



正如 所见， 没 有冲突 发生， 仅是一 次简单 快进。 现在 jessica 开 始合并 john 的工作 
origin/ master ) ： 
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$ git merge origin/ master 
Auto-merging lib/simplegit.rb 
Merge made by recursive, 
lib/simplegit.rb I 2 +- 
1 files changed, 1 insertions ( + 



deletions (-) 



所有 的合并 都非常 干净。 现在 jessica 的 提交历 史如图 5-9 所示: 




图 5.9: 合并 john 的 更新后 jessica 的提 交历史 



现在 jessica 已经 可以在 自己的 master 分支 中访问 origin/master 的 最新改 动了， 所以她 
应该 可以成 功推送 最后的 合并结 果到服 务器上 （ 假设 john 此时 没再推 送新数 据上来 ） ： 



$ git push origin master 



To jessica@githost:simplegit.git 

72bbc59..8059c15 master -> master 



至此， 每 个开发 者都提 交了若 干次， 且成 功合并 了对方 的工作 成果， 最新的 提交历 史如图 

5-10 所示： 




1 



图 5.10: Jessica 推 送数据 后的提 交历史 

以上就 是最简 单的协 作方式 之一： 先在 自己的 特性分 支中工 作一段 时间， 完 成后合 并到自 
己的 master 分支； 然后下 载合并 origin/master 上 的更新 （ 如果 有的活 ） ， 再 推回远 程服务 
器。 一般的 协作流 程如图 5-11 所示： 

5.2.3 私 有团队 间协作 

现在 我们来 看更大 一点规 模的私 有团队 协作。 如 果有几 个小组 分头负 责若干 特性的 开发和 
集成， 那他们 之间的 协作过 程是怎 样的。 
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Jessica 




git commit 



3 



git merge 



3 



I git clone furl) 



git push origin I 



• qit fetch origin 



git push origin I 




git clone (url) • 



git fetch origin > 



nit f^tcl'i 'jr nii'ih 



git commit 



5 



git merge 



5 



Jessica 


通 


Servsr 


疆 


John 



图 5.11: 多用 户共享 仓库协 作方式 的一般 工作流 程时序 

假设 john 和 jessica —起 负责 开发某 项特性 A, 而同时 jessica 和 josie —起负 责开发 
另一 项功能 B。 公司 使用典 型的集 成管理 员式工 作流， 每 个组都 有一名 管理员 负责集 成本组 
代码， 及更新 项目主 仓库的 master 分支。 所有 开发都 在代表 小组的 分支上 进行。 

让我 们跟随 jessica 的视角 看看她 的工作 流程。 她 参与开 发两项 特性， 同 时和不 同小组 
的开发 者一起 协作。 克 隆生成 本地仓 库后， 她 打算先 着手开 发特性 A。 于 是创建 了新的 
featureA 分支， 继 而编写 代码： 



# Jessica's Machine 
$ git checkout - b featureA 
Switched to a new branch "featureA" 
$ vim lib/simplegit.rb 

$ git commit -am 'add limit to log function' 
[featureA 3300904] add limit to log function 
1 files changed, 1 insertions( + ), 1 deletions ( — ) 



此刻， 她需 要分享 目前的 进展给 john, 于 是她将 自己的 featureA 分支提 交到服 务器。 由 
于 jessica 没 有权限 推送数 据到主 仓库的 master 分支 （ 只有 集成管 理员有 此权限 ） ， 所以 
只 能将此 分支推 上去同 john 共享 协作： 



$ git push origin featureA 



To jessica@githost:simplegit.git 



117 



第 5 章 分布式 Git 



Scott Chacon Pro Git 



[new branch] featureA -> featureA 



Jessica 发 邮件给 john 让他上 来看看 featureA 分 支上的 进展。 在 等待他 的反馈 之前， 
Jessica 决 定继续 工作， 和 josie —起 开发 features 上 的特性 B。 当然， 先 创建此 分支， 分 
叉点 以服务 器上的 master 为 起点： 



# Jessica's Machine 
$ git fetch origin 

$ git checkout -b featureB origin/ master 
Switched to a new branch "featureB" 



随后， jessica 在 featureB 上提交 了若干 更新: 



$ vim lib/simplegit.rb 

$ git commit -am 'made the Is- tree function recursive' 
[featureB e5b0fdc] made the Is- tree function recursive 

1 files changed, 1 insertions( + ), 1 deletions (-) 
$ vim lib/simplegit.rb 
$ git commit -am 'add Is- files' 
[featureB 8512791] add Is- files 

1 files changed, 5 insertions( + ), 0 deletions ( — ) 



现在 jessica 的 更新历 史如图 5-12 所示: 



master 



- { 4b078 ^ledee ^^- 



33009 




e5b0f 



丄 



图 5.12: Jessica 的更 新历史 



Jessica 正 准备推 送自己 的进展 上去， 却收到 josie 的 来信， 说是她 已经将 自己的 工作推 
到服务 器上的 featureBee 分 支了。 这样， Jessica 就必 须先将 josie 的 代码合 并到自 己本地 
分 支中， 才能再 一起推 送回服 务器。 她用 git fetch 下载 josie 的最新 代码： 
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$ git fetch origin 

From jessica@githost:simplegit 

* [new branch] featureBee -> origin/featureBee 



然后 jessica 使用 git merge 将 此分支 合并到 自己分 支中： 

$ git merge origin/featureBee 
Auto-merging lib/simplegit.rb 
Merge made by recursive. 

lib/simplegit.rb I 4 ++++ 

1 files changed, 4 insertions( + ), 0 deletions ( — ) 

合并很 顺利， 但另外 有个小 问题： 她 要推送 自己的 featureB 分支 到服务 器上的 featureBee 
分支 上去。 当然， 她 可以使 用冒号 （：） 格式指 定目标 分支： 

$ git push origin featureB:featureBee 

To jessica@githost:simplegit.git 

fba9af8..cd685d1 featureB -> featureBee 

我们 称此为 -refspec -。 更多 有关于 Git refspec 的讨 论和使 用方式 会在第 九章作 详细阐 

述。 

接 下来， john 发 邮件给 jessica 告 诉她， 他看 了之后 作了些 修改， 已 经推回 服务器 
featureA 分支， 请她过 目下。 于是 jessica 运行 git fetch 下 载最新 数据： 

$ git fetch origin 

From jessica@githost:simplegit 

3300904..aad881d featureA -> origin/featureA 



接 下来便 可以用 git log 查看更 新了些 什么： 
$ git log origin/featureA A featureA 

commit aad881d154acdaeb2b6b18ea0e827ed8a6d671e6 
Author: John Smith <jsmith@example.com> 
Date: Fri May 29 19:57:33 2009 -0700 

changed log output to 30 from 25 
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最后， 她将 john 的工作 合并到 自己的 featureA 分 支中: 

$ git checkout featureA 
Switched to branch "featureA" 
$ git merge origin/featureA 
Updating 3300904..aad881d 
Fast forward 

lib/simplegit.rb I 10 +++++++++- 
1 files changed, 9 insertions( + ), 1 deletions ( — ) 



Jessica 稍做一 番修 整后同 步到服 务器: 



$ git commit -am 'small tweak' 




[featureA ed774b3] small tweak 




1 files changed, 1 insertions( + ) 


1 deletions (-) 


$ git push origin featureA 




To jessica@githost:simplegit.git 




3300904..ed774b3 featureA -> 


featureA 



现在的 jessica 提交历 史如图 5-13 所示: 



origin/featureA 




origin/featureBee 



图 5.13: 在 特性分 支中提 交更新 后的提 交历史 

现在， jessica, Josie 和 john 通知集 成管理 员服务 器上的 featureA 及 featureBee 分支已 
经准 备好， 可以 并入主 线了。 在管理 员完成 集成工 作后， 主分支 上便多 出一个 新的合 并提交 
( 5399e ) , 用 fetch 命令更 新到本 地后， 提交历 史如图 5-14 所示： 

许多 开发小 组改用 Git 就是 因为它 允许多 个小组 间并行 工作， 而在 稍后恰 当时机 再行合 
并。 通过共 享远程 分支的 方式， 无需干 扰整体 项目代 码便可 以开展 工作， 因 此使用 Git 的小 
型团 队间协 作可以 变得非 常灵活 自由。 以上 工作流 程的时 序如图 5-15 所示： 
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I 丁 I 



orlgln/feaiureA 
工 



- { 4b07B ledee^-^— ^33009 ^ aad88 ^^- 774b3 ) 



featureA I I origin/ master 

T 



， 




图 5.14: 合并 特性分 支后的 j essica 提 交历史 




"push co in f-atLit^A 



i'r" 1 ''' 1 ? 



lit m— rg— cn A 



git commrt on B I 



git merge on Bl 



git commtt on Al 



git commit on B I 



git fetch cfigr 



qtt push crign featureB:featirgBeg 



git feKh oriqn 



git push origin featureA 



Jessica I John Josle Server: featureA Server: featureBee 



图 5.15: 团 队间协 作工作 流程基 本时序 



5.2.4 公 开的小 型项目 

上面说 的是私 有项目 协作， 但要 给公开 项目作 贡献， 情况就 有些不 同了。 因 为你没 有直接 
更新 主仓库 分支的 权限， 得寻 求其它 方式把 工作成 果交给 项目维 护人。 下面 会介绍 两种方 
法， 第一 种使用 git 托管服 务商提 供的仓 库复制 功能， 一般 称作 fork, 比如 repo.or.cz 和 
GitHub 都支持 这样的 操作， 而 且许多 项目管 理员都 希望大 家使用 这样的 方式。 另一 种方法 
是通 过电子 邮件寄 送文件 补丁。 

但不 管哪种 方式， 起先 我们总 需要克 隆原始 仓库， 而 后创建 特性分 支开展 工作。 基 本工作 
流程 如下： 



$ git clone (url ) 
$ cd project 

$ git checkout - b featureA 
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$ (work) 
$ git commit 
$ (work) 
$ git commit 



你可能 想到用 rebase-i 将 所有更 新先变 作单个 提交， 又或者 想重新 安排提 交之间 的差异 
补丁， 以 方便项 目维护 者审阅 口有关 交互式 衍合操 作的细 节见第 六章。 

在完 成了特 性分支 开发， 提交 给项目 维护者 之前， 先到原 始项目 的页面 上点击 "Fork" 按 
钮， 创 建一个 自己可 写的公 共仓库 （译注 ： 即 下面的 uH 部分， 参照 后续的 例子， 应该是 

git://githost/simplegit.git ) 。 然后将 此仓 库添加 为本地 的第二 个远端 仓库， 姑 且称为 myfork: 



$ git remote add myfork (url) 

你 需要将 本地更 新推送 到这个 仓库。 要是 将远端 master 合 并到本 地再推 回去， 还 不如把 
整 个特性 分支推 上去来 得干脆 直接。 而且， 假 若项目 维护者 未采纳 你的贡 献的话 （不 管是直 
接合 并还是 cherry pick ) , 都不 用回退 （ rewind ) 自己的 master 分支。 但 若维护 者合并 
或 cherry-pick 了你的 工作， 最后 总还可 以从他 们的更 新中同 步这些 代码。 好吧， 现 在先把 
featureA 分支 整个推 上去： 



$ git push myfork featureA 



然 后通知 项目管 理员， 让 他来抓 取你的 代码。 通 常我们 把这件 事叫做 pull request. 可 
以 直接用 GitHub 等网站 提供的 "pull request" 按钮 自动发 送请求 通知； 或 手工把 git 
request-pull 命 令输出 结果电 邮给项 目 管 理员。 

request-pull 命令接 受两个 参数， 第 一个是 本地特 性分支 开始前 的原始 分支， 第二 个是请 
求 对方来 抓取的 Git 仓库 URL ( 译注： 即下面 myfork 所 指的， 自己可 写的公 共仓库 ） 。 比 
如现在 jessica 准 备要给 john 发一个 pull requst, 她之 前在自 己的特 性分支 上提交 了两次 
更新， 并把 分支整 个推到 了服务 器上， 所以 运行该 命令会 看到： 

$ git request-pull origin/ master myfork 

The following changes since commit 1edee6b1d61823a2de3b09c160d7080b8d1b3a40: 
John Smith (1): 

added a new function 

are available in the git repository at: 

git://githost/simplegit.git featureA 

Jessica Smith (2): 

add limit to log function 
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change log output to 30 from 25 

lib/simplegit.rb I 10 +++++++++- 

1 files changed, 9 insertions( + ), 1 deletions ( — ) 

输出 的内容 可以直 接发邮 件给管 理者， 他们就 会明白 这是从 哪次提 交开始 旁支出 去的， 该 
到哪 里去抓 取新的 代码， 以 及新的 代码增 加了哪 些功能 等等。 

像 这样随 时保持 自己的 master 分支 和官方 origin/master 同步， 并将 自己的 工作限 制在特 
性分 支上的 做法， 既 方便又 灵活， 采纳 和丢弃 都轻而 易举。 就算 原始主 干发生 变化， 我们也 
能重新 衍合提 供新的 补丁。 比 如现在 要开始 第二项 特性的 开发， 不要在 原来已 推送的 特性分 
支上 继续， 还是 按原始 master 开始： 

$ git checkout - b featureB origin/ master 
$ (work) 
$ git commit 

$ git push myfork featureB 
$ (email maintainer) 
$ git fetch origin 

现在， a、 b 两个 特性分 支各不 相扰， 如同 竹筒里 的两颗 豆子， 队列中 的两个 补丁， 你 
随时都 可以分 别从头 写过， 或者 衍合， 或者 修改， 而不用 担心特 性代码 的交叉 混杂。 如图 

5-16 所示： 




图 5.16: featureB 以 后的提 交历史 

假设项 目管理 员接纳 了许多 别人提 交的补 丁后， 准备要 采纳你 提交的 第一个 分支， 却发现 
因 为代码 基准不 一致， 合并 工作无 法正确 干净地 完成。 这 就需要 你再次 衍合到 最新的 oHgin/ 
master, 解 决相关 冲突， 然后 重新提 交你的 修改： 

$ git checkout featureA 
$ git rebase origin/ master 
$ git push 一 f myfork featureA 
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图 5.17: feature A 重 新衍合 后的提 交历史 



自然， 这会重 写提交 历史， 如图 5-17 所示： 

注意， 此 时推送 分支必 须使用 -f 选项 （ 译注： 表示 force, 不作 检查强 制重写 ） 替 换远程 
已有的 featureA 分支， 因 为新的 commit 并 非原来 的后续 更新。 当然 你也可 以直接 推送到 
另 一个新 的分支 上去， 比 如称作 fe a t ure Av2。 

再考虑 另一种 情形： 管理员 看过第 二个分 支后觉 得思路 新颖， 但想 请你改 下具体 实现。 
我 们只需 以当前 origin/master 分支为 基准， 开始一 个新 的特 性分支 featureBW, 然后 把原来 
的 featureB 的 更新拿 过来， 解决 冲突， 按要求 重新实 现部分 代码， 然后 将此特 性分支 推送上 
去： 



$ git checkout - b featureBv2 origin/ master 
$ git merge -- no-commit ― squash featureB 
$ (change implementation ) 
$ git commit 

$ git push myfork featureBv2 



这里的 一squash 选 项将目 标分支 上的所 有更改 全拿来 应用到 当前分 支上， 而 一no-commit 
选 项告诉 Git 此时 无需自 动生成 和记录 （合并 ） 提交。 这样， 你 就可以 在原来 代码基 础上， 
继续 工作， 直到最 后一起 提交。 

好了， 现 在可以 请管理 员抓取 featureBN/2 上的 最新代 码了， 如图 5-18 所示： 



master I I ortgln/nuster 




( e5b0f ) 一 ~ | fcaiurtB 



图 5.18: featureBv2 之 后的提 交历史 



5.2.5 公 开的大 型项目 

许 多大型 项目都 会立有 一套自 己的接 受补丁 流程， 你应 该注意 下其中 细节。 但多数 项目都 
允 许通过 开发者 邮件列 表接受 补丁， 现在 我们来 看具体 例子。 
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整个 工作流 程类似 上面的 情形： 为每个 补丁创 建独立 的特性 分支， 而 不同之 处在于 如何提 
交这些 补丁。 不需要 创建自 己可写 的公共 仓库， 也 不用将 自己的 更新推 送到自 己的服 务器， 
你 只需将 每次提 交的差 异内容 以电子 邮件的 方式依 次发送 到邮件 列表中 即可。 

$ git checkout - b topicA 
$ (work) 
$ git commit 
$ (work) 
$ git commit 



如此一 番后， 有了 两个提 交要发 到邮件 列表。 我们 可以用 git format-patch 命令 来生成 
mbox 格式 的文件 然后作 为附件 发送。 每个 提交都 会封装 为一个 .patch 后缀的 mbox 文件， 
但其 中只包 含一封 邮件， 邮 件标题 就是提 交消息 （ 译注： 额外有 前缀， 看例子 ） ， 邮 件内容 
包 含补丁 正文和 Git 版 本号。 这种 方式的 妙处在 于接受 补丁时 仍可保 留原来 的提交 消息， 请 
看接 下来的 例子： 

$ git format-patch -M origin/ master 

000 1 - ad d-li mit-to-log-function. patch 

0002- changed-log-output-to-30-from-25. patch 



format-patch 命令 依次创 建补丁 文件， 并 输出文 件名。 上面的 -M 选 项允许 Git 检 查是否 
有对 文件重 命名的 提交。 我 们来看 看补丁 文件的 内容： 

$ cat 0001-add-limit-to-log-f unction. patch 

From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001 
From: Jessica Smith <jessica@example.com> 
Date: Sun, 6 Apr 2008 10:17:23 -0700 
Subject: [PATCH 1/2] add limit to log function 

Limit log functionality to the first 20 
lib/simplegit.rb I 2 +- 

1 files changed, 1 insertions( + ), 1 deletions (-) 

diff —― git a/lib/simplegit.rb b/lib/simplegit.rb 
index 76f47bc..f9815f 1 100644 
— a/lib/simplegit.rb 
+++ b/lib/simplegit.rb 
@@ -14,7 +14,7 @@ class SimpleGit 
end 



125 



第 5 章 分布式 Git 



Scott Chacon Pro Git 



def log (treeish = 'master') 
- command ("git log #{treeish}") 
+ command ("git log - n 20 #{treeish}") 

end 

def ls-tree(treeish = 'master') 
1.6.2.rc1.20.g8c5b.dirty 



如果有 额外信 息需要 补充， 但又 不想放 在提交 消息中 说明， 可以 编辑这 些补丁 文件， 在第 
—个 一- 行之 前添加 说明， 但 不要修 改下面 的补丁 正文， 比如例 子中的 Limit log functionality 
to the first 20 部分。 这样， 其它开 发者能 阅读， 但 在采纳 补丁时 不会将 此合并 进来。 

你可 以用邮 件客户 端软件 发送这 些补丁 文件， 也可以 直接在 命令行 发送。 有 些所谓 智能的 
邮 件客户 端软件 会自作 主张帮 你调整 格式， 所 以粘贴 补丁到 邮件正 文时， 有可 能会丢 失换行 
符 和若干 空格。 Git 提 供了一 个通过 IMAP 发 送补丁 文件的 工具。 接下 来我会 演示如 何通过 
Gmail 的 IMAP 月 艮务器 发送。 另夕 卜， 在 Git 源代码 中有个 Documentation/SubmittingPatches 
文件， 可 以仔细 读读， 看看 其它邮 件程序 的相关 导引。 

首先在 V.gitconfig 文件 中配置 imap 项。 每 个选项 都可用 git config 命 令分别 设置， 当然 
直 接编辑 文件添 加以下 内容更 便捷： 

[imap] 

folder = "[Gmail]/Drafts" 

host = imaps://imap.gmail.com 

user = user@gmail.com 

pass = p4ssw0rd 

port = 993 

sslverify = false 



如 果你的 IMAP 服 务器没 有启用 SSL, 就无 需配置 最后那 两行， 并且 host 应该以 imap:// 
开 头而不 再是有 s 的 imaps:/ 八 保存 配置文 件后， 就能用 git send-email 命令把 补丁作 为邮件 
依次 发送到 指定的 IMAP 服务器 上的文 件夹中 （ 译注： 这 里就是 Gmail 的 [GmailVDrafts 文 
件夹。 但如 果你的 语言设 置不是 英文， 此处的 文件夹 Drafts 字样 会变为 对应的 语言。 ） ： 

$ git send- email *. patch 

000 1- added- limit-to-log- function.patch 

0002- changed-log-output-to-30-from-25. patch 

Who should the emails appear to be from? [Jessica Smith <jessica@example.com>] 
Emails will be sent from: Jessica Smith <jessica@example.com> 
Who should the emails be sent to? jessica@example.com 
Message-ID to be used as In- Reply- To for the first email? y 



126 



Scott Chacon Pro Git 



5.3 节 项目 的管理 



接 下来， G it 会 根据每 个补丁 依次输 出类似 下面的 日 志： 

( mbox) Adding cc: Jessica Smith <jessica@example.com> from 

Mine 'From: Jessica Smith <j ess ica@example.com>' 
OK. Log says: 

Sendmail: / usr/sbin/sendmail -i jessica@example.com 
From: Jessica Smith <jessica@example.com> 
To: jessica@example.com 

Subject: [PATCH 1/2] added limit to log function 
Date: Sat, 30 May 2009 13:29:15 -0700 

Message-Id: < 12437 15356-61 726-1 -git-send-email-jessica@example.com> 
X-Mailer: git- send- email 1.6.2.rc1.20.g8c5b.dirty 
In— Reply— To: <y> 
References: <y> 

Result: OK 



最后， 到 Gmail 上打开 Drafts 文 件夹， 编 辑这些 邮件， 修 改收件 人地址 为邮件 列表地 
址， 另外 给要抄 送的人 也加到 Cc 列 表中， 最后 发送。 

5.2.6 小结 

本节主 要介绍 了常见 Git 项 目协作 的工作 流程， 还有 一些帮 助处理 这些工 作的命 令和工 
具。 接下来 我们要 看看如 何维护 Git 项目， 并成 为一个 合格的 项目管 理员， 或 是集成 经理。 



5.3 项目 的管理 

既然 是相互 协作， 在贡献 代码的 同时， 也免不 了要维 护管理 自己的 项目。 像 是怎么 处理别 

人用 format-patch 生成的 补丁， 或是 集成远 端仓库 上某个 分支上 的变化 等等。 但无论 是管理 
代码 仓库， 还是帮 忙审核 收到的 补丁， 都 需要同 贡献者 约定某 种长期 可持续 的工作 方式。 

5.3.1 使 用特性 分支进 行工作 

如 果想要 集成新 的代码 进来， 最好局 限在特 性分支 上做。 临时 的特性 分支可 以让你 随意尝 
试， 进退 自如。 比如 碰上无 法正常 工作的 补丁， 可以 先搁在 那边， 直到 有时间 仔细核 查修复 

为止。 创 建的分 支可以 用相关 的主题 关键字 命名， 比如 mb y _di ent 或 者其它 类似的 描述性 
词语， 以帮 助将来 回忆。 Git 项目 本身还 时常把 分支名 称分置 于不同 命名空 间下， 比如 SC / 
ruby_client 就说 明这是 sc 这 个人贡 献的。 现 在从当 前主干 分支为 基础， 新 建临时 分支： 



$ git branch sc/ruby—client master 

另外， 如 果你希 望立即 转到分 支上去 工作， 可以用 checkout -b: 
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$ git checkout - b sc/ruby— client master 



好了， 现在已 经准备 妥当， 可以试 着将别 人贡献 的代码 合并进 来了。 之后评 估一下 有没有 
问题， 最 后再决 定是不 是真的 要并入 主干。 

5.3.2 采纳来 自邮件 的补丁 

如 果收到 一个通 过电邮 发来的 补丁， 你 应该先 把它应 用到特 性分支 上进行 评估。 有 两种应 

用 补丁的 方法： git apply 或者 git am。 

使用 apply 命令应 用补丁 

如果 收到的 补丁文 件是用 git diff 或 由其它 Unix 的 diff 命令 生成， 就该用 git apply 命令来 
应用 补丁。 假设 补丁文 件存在 Amp/patch- mby-client.patch, 可 以这样 运行： 



$ git apply /tmp/patch-ruby-client.patch 



这会修 改当前 工作目 录下的 文件， 效 果基本 与运行 patch - P 1 打补丁 一样， 但它 更为严 
格， 且不 会出现 混乱。 如果是 git diff 格式 描述的 补丁， 此命 令还会 相应地 添加， 删除， 重 
命名 文件。 当然， 普通的 patch 命 令是不 会这么 做的。 另外请 注意， git apply 是一个 事务性 
操作的 命令， 也就 是说， 要么 所有补 丁都打 上去， 要 么全部 放弃。 所以不 会出现 patch 命令 
那样， 一 部分文 件打上 了补丁 而另一 部分却 没有， 这样 一种不 上不下 的修订 状态。 所 以总的 
来说， git apply 要比 patch 严谨 许多。 因 为仅仅 是更新 当前的 文件， 所 以此命 令不会 自动生 
成提交 对象， 你得 手工缓 存相应 文件的 更新状 态并执 行提交 命令。 

在实际 打补丁 之前， 可 以先用 git apply -check 查看补 丁是否 能够干 净顺利 地应用 到当前 
分 支中： 

$ git apply -- check 0001-seeing-if-this-helps-the-gem. patch 

error: patch failed: ticgit.gemspec:1 

error: ticgit.gemspec: patch does not apply 



如果没 有任何 输出， 表示 我们可 以顺利 采纳该 补丁。 如果有 问题， 除了报 告错误 信息之 

外， 该命令 还会返 回一个 非零的 状态， 所以在 shell 脚本 里可用 于检测 状态。 

使用 am 命令应 用补丁 

如 果贡献 者也用 Git, 且擅 于制作 format-patch 补丁， 那你 的合并 工作将 会非常 轻松。 因 
为 这些补 丁中除 了文件 内容差 异外， 还包 含了作 者信息 和提交 消息。 所以请 鼓励贡 献者用 
format-patch 生成 补丁。 对于 传统的 diff 命令 生成的 补丁， 则 只能用 git apply 处理。 

对于 format-patch 制作 的新式 补丁， 应 当使用 git am 命令。 从 技术上 来说， git am 能够读 
取 mbox 格式的 文件。 这是种 简单的 纯文本 文件， 可以包 含多封 电邮， 格 式上用 From 加 
空格 以及随 便什么 辅助信 息所组 成的行 作为分 隔行， 以区 分每封 邮件， 就像 这样： 
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From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001 
From: Jessica Smith <jessica@example.com> 
Date: Sun, 6 Apr 2008 10:17:23 - 0700 
Subject: [PATCH 1/2] add limit to log function 



Limit log functionality to the first 20 




这是 format-patch 命 令输出 的开头 几行， 也是一 个 有效的 mbox 文件 格式。 如果 有人用 
git send-email 给你发 了一个 补丁， 你 可以将 此邮件 下载到 本地， 然 后运行 git am 命 令来应 
用这个 补丁。 如果你 的邮件 客户端 能将多 封电邮 导出为 mbox 格式的 文件， 就 可以用 git am 
一 次性应 用所有 导出的 补丁。 

如果贡 献者将 format-patch 生成的 补丁文 件上传 到类似 Request Ticket 一 样的任 务处理 
系统， 那么 可以先 下载到 本地， 继 而使用 git am 应用该 补丁： 

$ git am 000 1-lim it-log-function. patch 
Applying: add limit to log function 



你会 看到它 被干净 地应用 到本地 分支， 并 自动创 建了新 的提交 对象。 作者信 息取自 邮件头 

From 和 Date, 提 交消息 则取自 Subject 以 及正文 中补丁 之前的 内容。 来 看具体 实例， 采纳 
之 前展示 的那个 mbox 电邮补 丁后， 最新的 提交对 象为： 



$ git log ― pretty=fuller - 1 

commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0 
Author: Jessica Smith <jessica@example.com> 
AuthorDate: Sun Apr 6 10:17:23 2008 -0700 
Commit: Scott Chacon <schacon@gmail.com> 
CommitDate: Thu Apr 9 09:19:06 2009 -0700 




add limit to log function 




Limit log functionality to the first 20 





Commit 部 分显示 的是采 纳补丁 的人， 以及 采纳的 时间。 而 Author 部分则 显示的 是原作 
者， 以 及创建 补丁的 时间。 

有时， 我们也 会遇到 打不上 补丁的 情况。 这多半 是因为 主干分 支和补 丁的基 础分支 相差太 
远， 但也可 能是因 为某些 依赖补 丁还未 应用。 这种情 况下， git am 会报 错并询 问该怎 么做： 

$ git am 0001 -see ing-if-this-h el ps-the-gem. patch 
Applying: seeing if this helps the gem 
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error: patch failed: ticgit.gemspec:1 

error: ticgit.gemspec: patch does not apply 

Patch failed at 0001. 

When you have resolved this problem run "git am -- resolved". 

If you would prefer to skip this patch, instead run "git am ― skip". 

To restore the original branch and stop patching run "git am ― abort". 



Git 会在有 冲突的 文件里 加入冲 突解决 标记， 这同合 并或衍 合操作 一样。 解 决的办 法也一 
样， 先 编辑文 件消除 冲突， 然 后暂存 文件， 最 后运行 git am -resolved 提 交修正 结果： 

$ (fix the file) 

$ git add ticgit.gemspec 

$ git am -- resolved 

Applying: seeing if this helps the gem 



如 果想让 Git 更智能 地处理 冲突， 可以用 -3 选项进 行三方 合并。 如 果当前 分支未 包含该 

补丁的 基础代 码或其 祖先， 那么 三方合 并就会 失败， 所 以该选 项默认 为关闭 状态。 一般来 
说， 如 果该补 丁是基 于某个 公开的 提交制 作而成 的话， 你 总是可 以通过 同步来 获取这 个共同 
祖先， 所以用 三方合 并选项 可以解 决很多 麻烦： 

$ git am - 3 0001 -seeing-if-this-helps-the-g em. patch 
Applying: seeing if this helps the gem 
error: patch failed: ticgit.gemspec:1 
error: ticgit.gemspec: patch does not apply 
Using index info to reconstruct a base tree- 
Falling back to patching base and 3- way merge- 
No changes -- Patch already applied. 



像 上面的 例子， 对于 打过的 补丁我 又再打 一遍， 自然 会产生 冲突， 但因为 加上了 _3 选 
项， 所以 它很聪 明地告 诉我， 无需 更新， 原 有的补 丁已经 应用。 

对于 一次应 用多个 补丁时 所用的 mbox 格式 文件， 可以用 am 命令的 交互模 式选项 -i, 这 
样 就会在 打每个 补丁前 停住， 询问 该如何 操作： 

$ git am - 3 - i mbox 
Commit Body is: 



seeing if this helps the gem 



Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all 
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在多个 补丁要 打的情 况下， 这 是个非 常好的 办法， 一 方面可 以预览 下补丁 内容， 同 时也可 
以 有选择 性的接 纳或跳 过某些 补丁。 

打完 所有补 丁后， 如 果测试 下来新 特性可 以正常 工作， 那就可 以安心 地将当 前特性 分支合 
并 到长期 分支中 去了。 

5.3.3 检出远 程分支 

如果贡 献者有 自己的 Git 仓库， 并将修 改推送 到此仓 库中， 那 么当你 拿到仓 库的访 问地址 
和 对应分 支的名 称后， 就 可以加 为远程 分支， 然 后在本 地进行 合并。 

比如， jessica 发 来一封 邮件， 说在 她代码 库中的 mby-diem 分支上 已经实 现了某 个非常 
棒的新 功能， 希望我 们能帮 忙测试 一下。 我们 可以先 把她的 仓库加 为远程 仓库， 然后 抓取数 
据， 完了再 将她所 说的分 支检出 到 本地来 测试： 



$ git remote add jessica git://github.com/jessica/myproject.git 
$ git fetch jessica 

$ git checkout - b rubyclient jessica/ruby-client 

若是 不久她 又发来 邮件， 说还有 个很棒 的功能 实现在 另一分 支上， 那 我们只 需重新 抓取下 
最新 数据， 然 后检出 那个分 支到本 地就可 以了， 无需 重复设 置远程 仓库。 

这 种做法 便于同 别人保 持长期 的合作 关系。 但前 提是要 求贡献 者有自 己的服 务器， 而我们 
也需要 为每个 人建一 个远程 分支。 有些贡 献者提 交代码 补丁并 不是很 频繁， 所 以通过 邮件接 
收补丁 效率会 更高。 同 时我们 自己也 不会希 望建上 百来个 分支， 却只从 每个分 支取一 两个补 
丁。 但若是 用脚本 程序来 管理， 或直 接使用 代码仓 库托管 服务， 就可以 简化此 过程。 当然， 
选择何 种方式 取决于 你和贡 献者的 喜好。 

使用 远程分 支的另 外一个 好处是 能够得 到提交 历史。 不管 代码合 并是不 是会有 问题， 至少 
我们 知道该 分支的 历史分 叉点， 所以默 认会从 共同祖 先开始 自动进 行三方 合并， 无需 -3 选 
项， 也不 用像打 补丁那 样祈祷 存在共 同的基 准点。 

如果只 是临时 合作， 只需用 git pull 命 令抓取 远程仓 库上的 数据， 合 并到本 地临时 分支就 
可 以了。 一次 性的抓 取动作 自 然不会 把该仓 库地址 加为远 程仓库 。 



$ git pull git://github.com/onetimeguy/project.git 
From git://github.com/onetimeguy/project 
* branch HEAD -> FETCH-HEAD 

Merge made by recursive. 



5.3.4 决断代 码取舍 

现 在特性 分支上 已合并 好了贡 献者的 代码， 是时候 决断取 舍了。 本节 将回顾 一些之 前学过 
的 命令， 以看 清将要 合并到 主干的 是哪些 代码， 从而 理解它 们到底 做了些 什么， 是否 真的要 
并入。 

一般我 们会先 看下， 特性分 支上都 有哪些 新增的 提交。 比如在 comrib 特性 分支上 打了两 
个 补丁， 仅查 看这两 个补丁 的提交 信息， 可以用 一not 选 项指定 要屏蔽 的分支 master, 这样 
就会剔 除重复 的提交 历史： 
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$ git log contrib ― not master 

commit 5b6235bd297351589efc4d73316f0a68d484f1 18 
Author: Scott Chacon <schacon@gmail.com> 
Date: Fri Oct 24 09:53:59 2008 -0700 

seeing if this helps the gem 

commit 7482e0d16d04bea79d0dba8988cc78df655f16a0 
Author: Scott Chacon <schacon@gmail.com> 
Date: Mon Oct 22 19:38:36 2008 - 0700 

updated the gemspec to hopefully work better 

还可以 查看每 次提交 的具体 修改。 请 牢记， 在 git log 后加 -p 选项将 展示每 次提交 的内容 
差异。 

如果想 看当前 分支同 其他分 支合并 时的完 整内容 差异， 有个小 窍门： 



$ git diff master 



虽 然能得 到差异 内容， 但请 记住， 结果 有可能 和我们 的预期 不同。 一 旦主干 master 在特 
性分支 创建之 后有所 修改， 那 么通过 diff 命 令来比 较的， 是最新 主干上 的提交 快照。 显然， 
这不是 我们所 要的。 比方在 master "分 支中某 个文件 里添了 一行， 然 后运行 上面的 命令， 简 
单的比 较最新 快照所 得到的 结论只 能是， 特性分 支中删 除了这 一行。 

这 个很好 理解： 如果 master "是特 性分支 的直接 祖先， 不会产 生任何 问题； 如果它 们的提 
交历 史在不 同的分 叉上， 那 么产生 的内容 差异， 看 起来就 像是增 加了特 性分支 上的新 代码， 
同时 删除了 master 分支 上的新 代码。 

实际上 我们真 正想要 看的， 是 新加入 到特性 分支的 代码， 也 就是合 并时会 并入主 干的代 
码。 所以， 准确 地讲， 我 们应该 比较特 性分支 和它同 master 分 支的共 同祖先 之间的 差异。 

我 们可以 手工定 位它们 的共同 祖先， 然 后与之 比较： 

$ git merge- base contrib master 
36c7dba2c95e6bbb78dfa822519ecfec6e1ca649 
$ git diff 36c7db 



但这 么做很 麻烦， 所以 Git 提供了 便捷的 ... 语法。 对于 diff 命令， 可以把 ... 加在 原始分 
支 （拥 有共同 祖先） 和当 前分支 之间： 



$ git diff master. ..contrib 




现在看 到的， 就 是实际 将要引 入的新 代码。 这是一 个非常 有用的 命令， 应该 牢记。 
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5.3.5 代 码集成 

一旦 特性分 支准备 停当， 接下 来的问 题就是 如何集 成到更 靠近主 线的分 支中。 此外 还要考 
虑维 护项目 的总体 步骤是 什么。 虽然 有很多 选择， 不过我 们这里 只介绍 其中一 部分。 

合 并流程 

一般最 简单的 情形， 是在 master 分 支中维 护稳定 代码， 然后 在特性 分支上 开发新 功能， 
或是 审核测 试别人 贡献的 代码， 接着将 它并入 主干， 最后 删除这 个特性 分支， 如此 反复。 来 
看 示例， 假设 当前代 码库中 有两个 分支， 分别为 ruby—client 和 php—dient, 如图 5- 19 所示。 
然 后先把 mb y _die n t 合并进 主干， 再合并 P hp_ C li en t, 最后的 提交历 史如图 5-20 所示。 



master 




个 



php— client 



图 5.19: 多个特 性分支 




t 



php_client 

图 5.20: 合并 特性分 支之后 
这是最 简单的 流程， 所 以在处 理大一 些的项 目时可 能会有 问题。 
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对 于大型 项目， 至少需 要维护 两个长 期分支 master 和 develop. 新代码 （ 图 5-21 中的 
ruby-client ) 将首 先并入 develop 分支 ( 图 5-22 中的 C8 ) , 经 过一个 阶段， 确认 develop 中 
的代码 已稳定 到可发 行时， 再将 master 分支 快进到 稳定点 （ 图 5-23 中的 C8 ) 。 而 平时这 
两 个分支 都会被 推送到 公开的 代码库 。 




ruby— client 



图 5.21: 特 性分支 合并前 



develop 




图 5.22: 特 性分支 合并后 



^ - 





图 5.23: 特 性分支 发布后 



这样， 在人们 克隆仓 库时就 有两种 选择： 既可 检出最 新稳定 版本， 确 保正常 使用； 也能检 
出开发 版本， 试 用最前 沿的新 特性。 你也 可以扩 展这个 概念， 先将所 有新代 码合并 到临时 
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特性 分支， 等 到该分 支稳定 下来并 通过测 试后， 再并入 develop 分支。 然后， 让时间 检验一 
切， 如 果这些 代码确 实可以 正常工 作相当 长一段 时间， 那就有 理由相 信它已 经足够 稳定， 可 
以放心 并入主 干分支 发布。 



大项 目的合 并流程 

Git 项目本 身有四 个长期 分支： 用于 发布的 master 分支、 用于 合并基 本稳定 特性的 next 
分支、 用于 合并仍 需改进 特性的 pu 分支 （ pu 是 proposed updates 的縮写 ） ， 以 及用于 
除错 维护的 maim 分支 （maint 取自 maintenance) 。 维护者 可以按 照之前 介绍的 方法， 
将贡 献者的 代码引 入为不 同的特 性分支 （如图 5-24 所示） ， 然 后测试 评估， 看哪些 特性能 
稳定 工作， 哪 些还需 改进。 稳定的 特性可 以并入 next 分支， 然后 再推送 到公共 仓库， 以供 
其他人 试用。 




图 5.24: 管理复 杂的并 行贡献 



仍需改 进的特 性可以 先并入 pu 分支。 直到它 们完全 稳定后 再并入 master 同时一 并检查 
下 next 分支， 将足 够稳定 的特性 也并入 master 所 以一般 来说， master 始 终是在 快进， next 
偶 尔做下 衍合， 而 Pu 则 是频繁 衍合， 如图 5-25 所示： 




图 5.25: 将特性 并入长 期分支 



并入 master 后 的特性 分支， 已经 无需保 留分支 索引， 放 心删除 好了。 Git 项目还 有一个 
maint 分支， 它 是以最 近一次 发行版 为基础 分化而 来的， 用于维 护除错 补丁。 所 以克隆 Git 
项目 仓库后 会得到 这四个 分支， 通过 检出不 同分支 可以了 解各自 进展， 或是试 用前沿 特性， 
或 是贡献 代码。 而维 护者则 通过管 理这些 分支， 逐 步有序 地并入 第三方 贡献。 
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衍合 与挑拣 （ cherry- pick ) 的流程 



一些维 护者更 喜欢衍 合或者 挑拣贡 献者的 代码， 而不是 简单的 合并， 因为这 样能够 保持线 
性 的提交 历史。 如果 你完成 了一个 特性的 开发， 并决 定将它 引入到 主干代 码中， 你可 以转到 
那个特 性分支 然后执 行衍合 命令， 好在你 的主干 分支上 （ 也 可能是 develop 分支 之类的 ） 重 
新提 交这些 修改。 如果这 些代码 工作得 很好， 你就可 以快进 master 分支， 得到 一个线 性的提 
交 历史。 

另一 个引入 代码的 方法是 挑拣。 挑拣 类似于 针对某 次特定 提交的 衍合。 它首 先提取 某次提 
交的 补丁， 然 后试着 应用在 当前分 支上。 如果某 个特性 分支上 有多个 commits, 但你 只想引 
入其中 之一就 可以使 用这种 方法。 也可能 仅仅是 因为你 喜欢用 挑拣， 讨厌 衍合。 假设 你有一 
个 类似图 5-26 的 工程。 



master 



{ 0b743 ) ^" ^ a6b4c^^— ^ f42c5 ) 




e43a6 



^ 5ddae ) 



ruby— client 



图 5.26: 挑拣 ( cherry- pick ) 之前 的历史 
如 果你希 望拉取 e43a6 到你 的主干 分支， 可以 这样： 



$ git cherry-pick e43a6fd3e94888d76779ad79fb568ed180e5fcdf 
Finished one cherry-pick. 

[master]: created a0a41a9: "More friendly message when locking the index fails. 1 
3 files changed, 17 insertions( + ), 3 deletions ( — ) 



这将 会引入 e43a6 的代 码， 但是 会得到 不同的 SHA-1 值， 因为应 用日期 不同。 现在 你的历 
史看起 来像图 5-27. 

现在， 你 可以删 除这个 特性分 支并丢 弃你不 想引入 的那些 commit。 

5.3.6 给发行 版签名 

你 可以删 除上次 发布的 版本并 重新打 标签， 也 可以像 第二章 所说的 那样建 立一个 新的标 
签。 如 果你决 定以维 护者的 身份给 发行版 签名， 应该这 样做： 



$ git tag - s v1.5 - m 'my signed 1.5 tag' 
You need a passphrase to unlock the secret key for 
user: "Scott Chacon <schacon@gmail.com>' 1 
1024-bit DSA key, ID F721C45A, created 2009-02-09 
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master 



i 




ruby 一 client 



图 5.27: 挑拣 ( cherry-pick ) 之后 的历史 

完 成签名 之后， 如 何分发 PGP 公钥 （public key) 是个 问题。 （译 者注： 分 发公钥 是为了 
验证标 签）。 还好， Git 的设计 者想到 了解决 办法： 可以把 key (既 公钥） 作为 blob 变 量写入 
Git 库， 然后把 它的内 容直接 写在标 签里。 gpg -list-keys 命令可 以显示 出你所 拥有的 key: 

$ gpg ― list-keys 

/Users/schacon/.gnupg/pubring.gpg 



pub 1024D/F721C45A 2009-02-09 [expires: 2010-02-09] 
uid Scott Chacon <schacon@gmail.com> 

sub 2048g/45D02282 2009-02-09 [expires: 2010-02-09] 

然后， 导出 key 的内容 并经由 管道符 传递给 gh hash- object, 之后钥 匙会以 blob 类 型写入 
Git 中， 最后返 回这个 blob 量的 SHA-1 值： 

$ gpg -a ― export F721C45A I git hash-object - w ― stdin 
659ef797d181633c87ec71ac3f9ba29fe5775b92 

现 在你的 Git 已 经包含 了这个 key 的内 容了， 可 以通过 不同的 SHA-1 值指定 不同的 key 来创 

建 标签。 



$ git tag -a maintainer-pgp-pub 659ef797d181633c87ec71ac3f9ba29fe5775b92 



在运行 git push —tags 命令 之后， maintainer-pgp-pub 标签, 就会公 布给所 有人。 如果 有人想 
要校验 标签， 他 可以使 用如下 命令导 入你的 key: 



$ git show maintainer-pgp-pub I gpg ― import 



人 们可以 用这个 key 校验 你签名 的所有 标签。 另外， 你 也可以 在标签 信息里 写入一 个操作 
向导， 用 户只需 要运行 git show <^ 9 >查 看标签 信息， 然后按 照你的 向导就 能完成 校验。 
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5.3.7 生 成内部 版本号 

因为 Git 不会 为每次 提交自 动附加 类似' v123' 的递增 序列， 所以如 果你想 要得到 一个便 
于理 解的提 交号可 以运行 git describe 命令。 Git 将 会返回 一个字 符串， 由 三部分 组成： 最近 
—次标 定的版 本号， 加上自 那次标 定之后 的提交 次数， 再加上 一段 SHA-1 值 of the commit 
you' re describing: 

$ git describe master 
v1.6.2-rc1-20-g8c5b85c 



这个字 符串可 以作为 快照的 名字， 方 便人们 理解。 如 果你的 Git 是你 自己下 载源码 然后编 
译安 装的， 你 会发现 git -version 命令的 输出和 这个字 符串差 不多。 如果 在一个 刚刚打 完标签 
的提交 上运行 describe 命令， 只 会得到 这次标 定的版 本号， 而 没有后 面两项 信息。 

git describe 命令只 适用于 有标注 的标签 （ 通过 -a 或者 -s 选项 创建 的标签 ） ， 所以发 行版的 
标签都 应该是 带有标 注的， 以保证 git describe 能够 正确的 执行。 你也 可以把 这个字 符串作 
为 checkout 或者 show 命令的 目标， 因为他 们最终 都依赖 于一个 简短的 SHA-1 值， 当然 如果这 
个 SHA-1 值失 效他们 也跟着 失效。 最近 Linux 内核为 了保证 SHA-1 值的唯 一性， 将 位数由 8 
位 扩展到 10 位， 这就导 致扩展 之前的 git describe 输出 完全失 效了。 

5.3.8 准 备发布 

现在 可以发 布一个 新的版 本了。 首 先要将 代码的 压縮包 归档， 方便那 些可怜 的还没 有使用 

Git 的 人们。 可 以使用 git archive: 

$ git archive master -- prefix='project/' I gzip > 、git describe master'.tar.gz 
$ Is *.tar.gz 

v1.6.2-rc1-20-g8c5b85c.tar.gz 



这个 压缩包 解压出 来的是 一个文 件夹， 里面 是你项 目的最 新代码 快照。 你也 可以用 类似的 

方法建 立一个 zip 压 缩包， 在 git archive 加上 —format=zip 选项： 



$ git archive master ― prefix='project/' ― format=zip > 、git describe master\zip 



现 在你有 了一个 tar.gz 压縮包 和一个 zip 压 縮包， 可以把 他们上 传到你 网站上 或者用 e-mail 
发给 别人。 

5.3.9 制 作简报 

是时 候通知 邮件列 表里的 朋友们 来检验 你的成 果了。 使用 git shortlog 命令可 以方便 快捷的 
制作 一份修 改日志 （changelog) , 告诉大 家上次 发布之 后又增 加了哪 些特性 和修复 了哪些 
bug 。 实 际上这 个命令 能够统 计给定 范围内 的所有 提交; 假如你 上一次 发布的 版本是 v 1 .0.1, 
下 面的命 令将给 出自从 上次发 布之后 的所有 提交的 简介： 
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$ git shortlog -- no-merges master ― not v1.0.1 
Chris Wanstrath (8): 

Add support for annotated tags to Grit:: 丁 ag 

Add packed-refs annotated tag support. 

Add Grit::Commit#to—patch 

Update version and History.txt 

Remove stray 、puts、 

Make ls-tree ignore nils 

Tom Preston-Werner (4): 
fix dates in history 
dynamic version method 
Version bump to 1.0.2 
Regenerated gemspec for version 1.0.2 



这就 是自从 v1.0.1 版 本以来 的所有 提交的 简介， 内容按 照作者 分组， 以便 你能快 速的发 
e-mail 给 他们。 



你学 会了如 何使用 Git 为 项目做 贡献， 也学 会了如 何使用 Git 维 护你的 项目。 恭喜！ 你已经 
成为 一名高 效的开 发者。 在 下一章 你将学 到更强 大的工 具来处 理更加 复杂的 问题， 之 后你会 
变 成一位 Git 大师。 
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现在， 你已经 学习了 管理或 者维护 Git 仓库， 实 现代码 控制所 需的大 多数日 常命令 和工作 
流程。 你 已经完 成了跟 踪和提 交文件 的基本 任务， 并且发 挥了暂 存区和 轻量级 的特性 分支及 
合并的 威力。 

接 下来你 将领略 到一些 Git 可 以实现 的非常 强大的 功能， 这些 功能你 可能并 不会在 日常操 
作中 使用， 但 在某些 时候你 也许会 需要。 



6.1 修 订版本 ( Revision ) 选择 

Git 允许 你通过 几种方 法来指 明特定 的或者 一定范 围内的 提交。 了解 它们并 不是必 需的， 
但是 了解一 下总没 坏处。 

6.1.1 单个修 订版本 

显 然你可 以使用 给出的 SHA-1 值来指 明一次 提交， 不 过也有 更加人 性化的 方法来 做同样 
的事。 本节 概述了 指明单 个提交 的诸多 方法。 

6.1.2 简短的 SHA 

Git 很 聪明， 它能 够通过 你提供 的前几 个字符 来识别 你想要 的那次 提交， 只 要你提 供的那 
部分 SHA-1 不短 于四个 字符， 并且没 有歧义 —— 也就 是说， 当 前仓库 中只有 一个对 象以这 
段 SHA- 1 开头。 

例如， 想要查 看一次 指定的 提交， 假设 你运行 git log 命令并 找到你 增加了 功能的 那次提 
交： 

$ git log 

commit 734713bc047d87bf7eac9674765ae793478c50d3 
Author: Scott Chacon <schacon@gmail.com> 
Date: Fri Jan 2 18:32:33 2009 -0800 

fixed refs handling, added gc auto, updated tests 

commit d921970aadf03b3cf0e71becdaab3147ba71cdef 
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Merge: 1c002dd... 35cfb2b... 

Author: Scott Chacon <schacon@gmail.com> 

Date: Thu Dec 11 15:08:43 2008 -0800 

Merge commit 'phedders/ rdocs' 

commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b 
Author: Scott Chacon <schacon@gmail.com> 
Date: Thu Dec 11 14:58:32 2008 -0800 

added some blame and merge stuff 

假设是 1c002dd... 。 如 果你想 git show 这次 提交， 下面的 命令是 等价的 （ 假 设简短 的版本 
没 有歧义 ） ： 

$ git show 1c002dd4b536e7479fe34593e72e6c6c1819e53b 
$ git show 1c002dd4b536e7479f 
$ git show 1c002d 

Git 可以 为你的 SHA- 1 值生 成出简 短且唯 一的 縮写。 如果 你传递 一abbrev-commit 给 git 
log 命令， 输出 结果里 就会使 用简短 且唯一 的值； 它 默认使 用七个 字符来 表示， 不过 必要时 
为 了避免 SHA-1 的 歧义， 会 增加字 符数： 

$ git log ― abbrev- commit ― pretty=oneline 
ca82a6d changed the version number 
085bb3b removed unnecessary test code 
all befO first commit 

通常在 一个项 目中， 使用 八到十 个字符 来避免 SHA-1 歧义 已经足 够了。 最大的 Git 项目 
之一， Linux 内核， 目前 也只需 要最长 40 个字 符中的 12 个 字符来 保持唯 一性。 

6.1.3 关于 SHA-1 的简 短说明 

许 多人可 能会担 心一个 问题： 在 随机的 偶然情 况下， 在 他们的 仓库里 会出现 两个具 有相同 
SHA-1 值的 对象。 那 会怎么 样呢？ 

如果 你真的 向仓库 里提交 了一个 跟之前 的某个 对象具 有相同 SHA-1 值的 对象， Git 将会 
发现 之前的 那个对 象已经 存在在 Git 数据 库中， 并认 为它已 经被写 入了。 如果 什么时 候你想 
再 次检出 那个对 象时， 你会 总是得 到先前 的那个 对象的 数据。 

不过， 你 应该了 解到， 这种情 况发生 的概率 是多么 微小。 SHA-1 摘要 长度是 20 字节， 
也就是 160 位。 为了 保证有 50% 的 概率出 现一次 冲突， 需要 2 8C) 个随 机哈希 的对象 （ 计算 
冲突 机率的 公式是 p= (n(n- 1)/2) * (1/2 口 160))。 2 80 是 1.2xl0 24 , 也就 是一亿 亿亿, 那是地 
球 上沙粒 总数的 1200 倍。 
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现在举 例说一 下怎样 才能产 生一次 SHA-1 冲突。 如果 地球上 65 亿的人 类都在 编程， 每 
人每秒 都在产 生等价 于整个 Linux 内 核历史 （ 一 百万个 Git 对象 ） 的 代码， 并将之 提交到 
一个 巨大的 Git 仓库 里面， 那 将花费 5 年的 时间才 会产生 足够的 对象， 使 其拥有 50% 的概 
率产 生一次 SHA-1 对象 冲突。 这要 比你编 程团队 的成员 同一个 晚上在 互不相 干的意 外中被 
狼 袭击并 杀死的 机率还 要小。 

6.1.4 分 支引用 

指明一 次提交 的最直 接的方 法要求 有一个 指向它 的分支 引用。 这样， 你就可 以在任 何需要 
一个 提交对 象或者 SHA-1 值的 Git 命令中 使用该 分支名 称了。 如果你 想要显 示一个 分支的 
最 后一次 提交的 对象， 例 如假设 topid 分 支指向 ca82a6d, 那么下 面的命 令是等 价的： 



$ git show ca82a6dff817ec66f44342007202690a93763949 
$ git show topic! 



如果 你想知 道某个 分支指 向哪个 特定的 SHA, 或者想 看任何 一个例 子中被 简写的 SHA- 
1, 你可以 使用一 个叫做 rev-parse 的 Git 探测 工具。 在第 9 章你 可以看 到关于 探测工 具的更 
多 信息； 简单 来说， rev-parse 是为了 底层操 作而不 是日常 操作设 计的。 不过， 有时 你想看 
Git 现在到 底处于 什么状 态时， 它可 能会很 有用。 这 里你可 以对你 的分支 运执行 rev-parse. 



$ git rev-parse topid 

Ca82a6dff817ec66f44342007202690a93763949 



6.1.5 引用 日志里 的简称 

在你 工作的 同时， Git 在后台 的工作 之一就 是保存 一份引 用日志 份记 录最近 几个月 

你的 HEAD 和分支 引用的 曰志。 

你可 以使用 git reflog 来查 看引用 日志： 



$ git reflog 

734713b... HEAD@{0}: commit: fixed refs handling, added gc auto, updated 

d921970... HEAD@{ 1 }: merge phedders/ rdocs: Merge made by recursive. 

1c002dd... HEAD@{2}: commit: added some blame and merge stuff 

1c36188... HEAD@{3}: rebase - i (squash): updating HEAD 

95df984... HEAD@{4}: commit: # This is a combination of two commits. 

1c36188... HEAD@{5}: rebase - i (squash): updating HEAD 

7e05da5... HEAD@{6}: rebase - i (pick): updating HEAD 



每 次你的 分支顶 端因为 某些原 因被修 改时， Git 就会为 你将信 息保存 在这个 临时历 史记录 
里面。 你 也可以 使用这 份数据 来指明 更早的 分支。 如果你 想查看 仓库中 HEAD 在五 次前的 
值， 你可 以使用 引用日 志的输 出中的 @{。} 引用： 
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$ git show HEAD@{5} 



你也可 以使用 这个语 法来查 看某个 分支在 一定时 间前的 位置。 例如， 想 看你的 master 分 
支昨天 在哪， 你可 以输入 



$ git show master@{yesterday} 



它就会 显示昨 天分支 的顶端 在哪。 这项 技术只 对还在 你引用 日志里 的数据 有用， 所 以不能 
用来查 看比几 个月前 还早的 提交。 

想要看 类似于 git log 输出格 式的引 用日志 信息， 你可 以运行 git log -g: 
$ git log -g master 

commit 73471 3bc047d87bf7eac9674765ae793478c50d3 

Reflog: master@{0} (Scott Chacon <schacon@gmail.com>) 

Reflog message: commit: fixed refs handling, added gc auto, updated 

Author: Scott Chacon <schacon@gmail.com> 

Date: Fri Jan 2 18:32:33 2009 -0800 

fixed refs handling, added gc auto, updated tests 

commit d921970aadf03b3cf0e71 becdaab3147ba71cdef 

Reflog: master@{ 1 } (Scott Chacon <schacon@gmail.com>) 

Reflog message: merge phedders/ rdocs: Merge made by recursive. 

Author: Scott Chacon <schacon@gmail.com> 

Date: Thu Dec 11 15:08:43 2008 -0800 

Merge commit 'phedders/ rdocs' 



需 要注意 的是， 引用日 志信息 只存在 于本地 —— 这 是一个 记录你 在你自 己的 仓库里 做过什 
么的 日志。 其 他人拷 贝的仓 库里的 引用日 志不会 和你的 相同； 而 你新克 隆一个 仓库的 时候， 

引用 日志是 空的， 因 为你在 仓库里 还没有 操作。 git show HEAD@Umonths.ago} 这条 命令只 
有在你 克隆了 一个项 目 至少 两个月 时才 会有用 —— 如果 你是五 分钟前 克隆的 仓库， 那 么它将 
不会 有结果 返回。 

6.1.6 祖 先引用 

另 一种指 明某次 提交的 常用方 法是通 过它的 祖先。 如果 你在引 用最后 加上一 个口， Git 将 
其 理解为 此次提 交的父 提交。 假 设你的 工程历 史是这 样的： 
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$ git log ― pretty=format: / %h %s' ― graph 

* 734713b fixed refs handling, added gc auto, updated tests 

* d921970 Merge commit 'phedders/ rdocs' 
l\ 

I * 35cfb2b Some rdoc changes 

* I 1c002dd added some blame and merge stuff 
1/ 

* 1c36188 ignore *.gem 

* 9b29157 add open3_detach to gemspec file list 



那么， 想看 上一次 提交， 你可 以使用 HEADQ 意思是 "HEAD 的父 提交" ： 
$ git show HEAD A 

commit d921970aadf03b3cf0e71 becdaab3147ba71cdef 

Merge: 1c002dd... 35cfb2b... 

Author: Scott Chacon <schacon@gmail.com> 

Date: Thu Dec 11 15:08:43 2008 -0800 

Merge commit 'phedders/ rdocs' 



你也 可以在 口 后 添加一 个数字 —— 例如， d92197CO 意思是 "d921970 的第 二父提 
交" 。 这种 语法只 在合并 提交时 有用， 因为合 并提交 可能有 多个父 提交。 第一 父提交 是你合 
并 时所在 分支， 而第二 父提交 是你所 合并的 分支： 

$ git show d921970 A 

commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b 
Author: Scott Chacon <schacon@gmail.com> 
Date: Thu Dec 11 14:58:32 2008 -0800 

added some blame and merge stuff 

$ git show d921970 A 2 

commit 35cfb2b795a55793d7cc56a6cc2060b4bb732548 
Author: Paul Hedderly <paul+git@mjr.org> 
Date: Wed Dec 10 22:22:03 2008 +0000 



Some rdoc changes 




另外 一个指 明祖先 提交的 方法是 ~。 这也 是指向 第一父 提交， 所以 HEAD~ 和 HEAD 口 是等 
价的。 当你 指定数 字的时 候就明 显不一 样了。 HEAD~2 是指 "第 一父 提交的 第一父 提交" ， 
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也就是 "祖父 提交" —— 它会根 据你指 定的次 数检索 第一父 提交。 例如， 在上 面列出 的历史 
记录 里面， HEAD〜3 会是 

$ git show HEAD-3 

commit 1c3618887afb5fbcbea25b7c013f4e21 14448b8d 
Author: Tom Preston-Werner <tom@mojombo.com> 
Date: Fri Nov 7 13:47:59 2008 -0500 

ignore *.gem 

也可 以写成 HEADCm 同样是 第一父 提交的 第一父 提交的 第一父 提交： 

$ git show HEAD AAA 

commit 1c3618887afb5fbcbea25b7c013f4e21 14448b8d 
Author: Tom Preston-Werner <tom@mojombo.com> 
Date: Fri Nov 7 13:47:59 2008 -0500 

ignore *.gem 

你也可 以混合 使用这 些语法 —— 你可 以通过 HEAD~3C|2 指明先 前引用 的第二 父提交 （假 
设它是 一个合 并提交 ） 。 

6.1.7 提 交范围 

现在你 已经可 以指明 单次的 提交， 让我们 来看看 怎样指 明一定 范围的 提交。 这在 你管理 
分支的 时候尤 显重要 —— 如果你 有很多 分支， 你可以 指明范 围来圈 定一些 问题的 答案， 比 
如： " 这个分 支上我 有哪些 工作还 没合并 到主分 支的？ " 

双点 

最常用 的指明 范围的 方法是 双点的 语法。 这种 语法主 要是让 Git 区分 出可从 一个分 支中获 
得而 不能从 另一个 分支中 获得的 提交。 例如， 假设 你有类 似于图 6-1 的提交 历史。 




图 6.1: 范围 选择的 提交历 史实例 



你想要 查看你 的试验 分支上 哪些没 有被提 交到主 分支， 那么 你就可 以使用 maste^experiment 
来让 Git 显示这 些提交 的日志 —— 这 句活的 意思是 "所 有可从 experiment 分 支中获 得而不 
能从 master 分支中 获得的 提交" 。 为 了使例 子简单 明了， 我使 用了图 标中提 交对象 的字母 
来代 替真实 日志的 输出， 所以会 显示： 
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$ git log master.. experiment 

D 

C 



另一 方面， 如果 你想看 相反的 —— 所有在 master 而不在 experiment 中 的分支 —— 你可以 
交换 分支的 名字。 experiment..master 显示所 有可在 master 获 得而在 experiment 中不 能的提 
交： 

$ git log experiment.. master 



这在你 想保持 experiment 分 支最新 和预览 你将合 并的提 交的时 候特别 有用。 这个 语法的 
另一种 常见用 途是查 看你将 把什么 推送到 远程： 

$ git log origin/ master..HEAD 



这条 命令显 示任何 在你当 前分支 上而不 在远程 origin 上的 提交。 如果 你运行 git push 并且 
的你 的当前 分支正 在跟踪 origin/master, 被 git log origin/master..HEAD 列出的 提交就 是将被 
传输 到服务 器上的 提交。 你也 可以留 空语法 中的一 边来让 Git 来假 定它是 HEAD。 例如， 
输入 git log origin/master.. 将得到 和上面 的例子 一样的 结果 —— Git 使用 HEAD 来代 替不存 
在的 一边。 

多点 

双 点语法 就像速 记一样 有用； 但是你 也许会 想针对 两个以 上的分 支来指 明修订 版本， 比如 
查 看哪些 提交被 包含在 某些分 支中的 一个， 但是不 在你当 前的分 支上。 Git 允 许你在 引用前 
使用 口字 符或者 一not 指明 你不希 望提交 被包含 其中的 分支。 因 此下面 三个命 令是等 同的： 

$ git log refA..refB 

$ git log A refA refB 

$ git log refB —not refA 

这样 很好， 因为 它允许 你在查 询中指 定多于 两个的 引用， 而 这是双 点语法 所做不 到的。 例 

如， 如果你 想查找 所有从 refA 或 refB 包 含的但 是不被 refC 包含的 提交， 你 可以输 入下面 中的一 
个 

$ git log refA refB A refC 

$ git log refA refB —not refC 
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这建 立了一 个非常 强大的 修订版 本查询 系统， 应 该可以 帮助你 解决分 支里包 含了什 么这个 
问题。 

最 后一种 主要的 范围选 择语法 是三点 语法， 这 个可以 指定被 两个引 用中的 一个包 含但又 

不被两 者同时 包含的 分支。 回过 头来看 一下图 6-1 里所列 的提交 历史的 例子。 如果 你想查 
看 master 或者 experimen 冲包含 的但不 是两者 共有的 引用， 你可 以运行 



$ git log master.. .experiment 

D 

C 

这 个再次 给出你 普通的 log 输 出但是 只显示 那四次 提交的 信息， 按 照传统 的提交 日 期排 

列。 

这种情 形下， log 命 令的一 个常用 参数是 一left-right, 它 会显示 每个提 交到底 处于哪 一侧的 
分支。 这 使得数 据更加 有用。 



$ git log ― left-right master.. .experiment 

< E 

> D 

> C 



有 了以上 工具， 让 Git 知道 你要察 看哪些 提交就 容易得 多了。 

6-2 交互 式暂存 

Git 提供了 很多脚 本来辅 助某些 命令行 任务。 这里， 你将看 到一些 交互式 命令， 它 们帮助 
你 方便地 构建只 包含特 定组合 和部分 文件的 提交。 在你修 改了一 大批文 件然后 决定将 这些变 
更分布 在几个 各有侧 重的提 交而不 是单个 又大又 乱的提 交时， 这些工 具非常 有用。 用 这种方 
法， 你可 以确保 你的提 交在逻 辑上划 分为相 应的变 更集， 以便于 供和你 一起工 怍的开 发者审 
阅。 如果 你运行 git add 时加上 -i 或者 一interactive 选项， Git 就 进入了 一个交 互式的 shell 模式， 
显 示一些 类似于 下面的 信息： 



$ git add - i 

staged unstaged path 
1: unchanged +0/-1 TODO 
2: unchanged +1/-1 index.html 
3: unchanged +5/-1 lib/simplegit.rb 



148 



Scott Chacon Pro Git 




6.2 节 交互 式暂存 


* * * Commands * * * 






1: status 2: update 


3: revert 4: add untracked 




5: patch 6: diff 


7: quit 8: help 




What now> 







你会看 到这个 命令以 一个 完全不 同的视 图显示 了你的 暂存区 —— 主要是 你通过 git status 得 
到 的那些 信息但 是稍微 简洁但 信息更 加丰富 一些。 它在 左侧列 出了你 暂存的 变更， 在 右侧列 
出 了未被 暂存的 变更。 

在这 之后是 一个命 令区。 这里 你可以 做很多 事情， 包 括暂存 文件， 撤回 文件， 暂存 部分文 
件， 加 入未被 追踪的 文件， 查 看暂存 文件的 差别。 

6.2.1 暂 存和撤 回文件 

如 果你在 What n0 w> 的提示 后输入 2 或者 u, 这个脚 本会提 示你那 些文件 你想要 暂存： 



What now> 2 




staged 


unstaged path 


1: unchanged 


+0/-1 TODO 


2: unchanged 


+ 1/-1 index.html 


3: unchanged 


+5/-1 lib/simplegit.rb 


Update» 





如果 想暂存 TODO 和 index.html, 你可 以输入 相应的 编号: 



Update» 1,2 




staged 


jnstaged path 


* 1: unchanged 


+0/-1 TODO 


* 2: unchanged 


+ 1/-1 index.html 


3: unchanged 


+5/-1 lib/simplegit.rb 


Update» 





每 个文件 旁边的 * 表示选 中的文 件将被 暂存。 如 果你在 updat e> 41 示后直 接敲入 回车， Git 
会替 你把所 有选中 的内容 暂存： 



Update» 
updated 2 paths 

*** Commands *** 
1: status 2: update 3: revert 4: add untracked 
5: patch 6: diff 7: quit 8: help 
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What now> 1 




staged 


unstaged path 


1: +0/-1 


nothing TODO 


2: 


nothing index.html 


3: unchanged 


+5/-1 lib/simplegit.rb 


现 在你可 以看到 TODO 和 index.html 文件 被暂存 了同时 simplegit.rb 文件仍 然未被 暂存。 


如果这 时你想 要撤回 TODO 文件， 就使用 3 或者 r (代表 revert, 恢复） 选项： 


*** Commands ** 




1: status 2: update 3: revert 4: add untracked 


5: patch 6: diff 7: quit 8: help 


What now> 3 




staged 


unstaged path 


1: +0/-1 


nothing TODO 


2: 


nothing index.html 


3: unchanged 


+5/-1 lib/simplegit.rb 


Revert» 1 




staged 


unstaged path 


* 1: +0/-1 


nothing TODO 


2: 


nothing index.html 


3: unchanged 


+5/-1 lib/simplegit.rb 


Revert» [enter] 




reverted one path 





再 次查看 Git 的 状态， 你 会看到 你已经 撤回了 TODO 文件 



*** Commands *** 
1: status 2: update 3: revert 4: add untracked 
5: patch 6: diff 7: quit 8: help 

What now> 1 

staged unstaged path 
1: unchanged +0/-1 TODO 
2: +1/-1 nothing index.html 
3: unchanged +5/-1 lib/simplegit.rb 



要查看 你暂存 内容的 差异， 你可 以使用 6 或者 d (表示 diff) 命令。 它会显 示你暂 存文件 

的 列表， 你可 以选择 其中的 几个， 显 示其被 暂存的 差异。 这 跟你在 命令行 下指定 git diff -- 
cached 非常 相似： 
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*** Commands *** 

1: status 2: update 3: revert 4: add untracked 

5: patch 6: diff 7: quit 8: help 
What now> 6 

staged unstaged path 

1: +1/-1 nothing index.html 
Review diff» 1 

diff -- git a/index. html b/index.html 
index 4d07108..4335f49 100644 

a/index. html 

+++ b/index.html 

@@ -16,7 +16,7 禱 Date Finder 

<p id="out">...</p> 

-<div id="footer">contact : support@github.com</div> 
+<div id="footer">contact : email.support@github.com</div> 

<script type="text/javascript"> 

通过这 些基本 命令， 你可 以使用 交互式 增加模 式更加 方便地 处理暂 存区。 

6.2.2 暂 存补丁 

只让 Git 暂存文 件的某 些部分 而忽略 其他也 是有可 能的。 例如， 你对 simplegit.rb 文 件作了 
两处修 改但是 只想暂 存其中 一个而 忽略另 一个， 在 Git 中实 现这一 点非常 容易。 在交 互式的 
提示 符下， 输入 5 或者 p (表示 patch, 补丁 ）。 Git 会询问 哪些文 件你希 望部分 暂存； 然后对 
于被 选中文 件的每 一节， 他会 逐个显 示文件 的差异 区块并 询问你 是否希 望暂存 他们： 



diff 一一 git a/lib/simplegit.rb b/lib/simplegit.rb 
index dd5ecc4..57399e0 100644 
— a/lib/simplegit.rb 
+++ b/lib/simplegit.rb 
@@ -22,7 +22,7 @@ class SimpleGit 
end 

def log (treeish = 'master') 
- command ("git log 一 n 25 #{treeish}'，) 
+ command ("git log 一 n 30 #{treeish}'，) 

end 

def blame(path) 
Stage this hunk [y，n,a,d,/，j，J，g，e，？]? 
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此处你 有很多 选择。 输入? 可 以显示 列表: 



Stage this hunk [y，n，a，d，/，j 丄 g,e ，？] ？ ？ 

y - stage this hunk 

n - do not stage this hunk 

a - stage this and all the remaining hunks in the file 

d - do not stage this hunk nor any of the remaining hunks in the file 

g - select a hunk to go to 

/ - search for a hunk matching the given regex 

j 一 leave this hunk undecided, see next undecided hunk 

J - leave this hunk undecided, see next hunk 

k 一 leave this hunk undecided, see previous undecided hunk 

K - leave this hunk undecided, see previous hunk 

s - split the current hunk into smaller hunks 

e - manually edit the current hunk 

？ 一 print help 




如果 你想暂 存各个 区块， 通常你 会输入 y 或者 n, 但是暂 存特定 文件里 的全部 区块或 者暂时 
跳过 对一个 区块的 处理同 样也很 有用。 如果 你暂存 了文件 的一个 部分而 保留另 外一个 部分不 
被 暂存， 你的 状态输 出看起 来会是 这样： 



What now> 1 

staged unstaged path 
1: unchanged +0/-1 TODO 
2: +1/-1 nothing index.html 
3: +1/-1 +4/-0 lib/simplegit.rb 



simplegit.rb 的状态 非常有 意思。 它显 示有几 行被暂 存了， 有几行 没有。 你 部分地 暂存了 
这个 文件。 在 这时， 你可 以退出 交互式 脚本然 后运行 git commit 来提 交部分 暂存的 文件。 
最后 你也可 以不通 过交互 式增加 的模式 来实现 部分文 件暂存 —— 你 可以在 命令行 下通过 git 

add - P 或者 git add --patch 来启动 同样的 脚本。 

6.3 储藏 ( Stashing ) 

经常 有这样 的事情 发生， 当你 正在进 行项目 中某一 部分的 工作， 里面 的东西 处于一 个比较 
杂乱的 状态， 而你 想转到 其他分 支上进 行一些 工作。 问 题是， 你不想 提交进 行了一 半的工 

作， 否则以 后你无 法回到 这个工 作点。 解决 这个问 题的办 法就是 git stash 命令。 

" '储 藏" "可以 获取你 工作目 录的中 间状态 —— 也就 是你修 改过的 被追踪 的文件 和暂存 
的变更 —— 并将它 保存到 一个未 完结变 更的堆 栈中， 随时可 以重新 应用。 

6.3.1 储藏你 的工作 

为了演 示这一 功能， 你 可以进 入你的 项目， 在一 些文件 上进行 工作， 有可能 还暂存 其中一 

个 变更。 如果 你运行 git status, 你可以 看到你 的中间 状态： 
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$ git status 

# On branch master 

# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 

# 

# modified: index.html 

# 

# Changes not staged for commit: 

# (use "git add <file>..." to update what will be committed ) 

# 

# modified: lib/simplegit.rb 

# 

现在你 想切换 分支， 但是你 还不想 提交你 正在进 行中的 工怍； 所 以你储 藏这些 变更。 为了 
往堆栈 推送一 个新的 储藏， 只 要运行 git stash: 

$ git stash 

Saved working directory and index state \ 



"WIP on master: 049d078 added the index file' 
HEAD is now at 049d078 added the index file 
(To restore them type "git stash apply") 




你的 工作目 录就干 净了： 

$ git status 

# On branch master 

nothing to commit (working directory clean) 



这时， 你 可以方 便地切 换到其 他分支 工作； 你的 变更都 保存在 栈上。 要查看 现有的 储藏， 
你可以 使用 git stash list: 

$ git stash list 

stash@{0}: WIP on master: 049d078 added the index file 
stash@{1}: WIP on master: c264051... Revert "added file— size 1 ' 
stash@{2}: WIP on master: 21d80a5... added number to log 



在 这个案 例中， 之前已 经进行 了两次 储藏， 所 以你可 以访问 到三个 不同的 储藏。 你 可以重 

新应用 你刚刚 实施的 储藏， 所采 用的命 令就是 之前在 原始的 stash 命 令的帮 助输出 里提示 
的： git stash a PP l V 。 如果你 想应用 更早的 储藏， 你可 以通过 名字指 定它， 像 这样： git stash 
apply stash@{2}。 如 果你不 指明， Git 默 认使用 最近的 储藏并 尝试应 用它： 
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$ git stash apply 

# On branch master 

# Changes not staged for commit: 

# (use "git add <file>..." to update what will be committed) 

# 

# modified: index.html 

# modified: lib/simplegit.rb 
# 



你可 以看到 Git 重 新修改 了你所 储藏的 那些当 时尚未 提交的 文件。 在 这个案 例里， 你尝试 
应用 储藏的 工作目 录是干 净的， 并且属 于同一 分支； 但是 一个干 净的工 作目录 和应用 到相同 
的分 支上并 不是应 用储藏 的必要 条件。 你可以 在其中 一个分 支上保 留一份 储藏， 随后 切换到 
另 外一个 分支， 再 重新应 用这些 变更。 在工 作目录 里包含 已修改 和未提 交的文 件时， 你也可 
以应 用储藏 —— Git 会给 出归并 冲突如 果有任 何变更 无法干 净地被 应用。 

对文件 的变更 被重新 应用， 但 是被暂 存的文 件没有 重新被 暂存。 想那样 的活， 你必 须在运 
行 git stash apply 命 令时带 上一个 --index 的 选项来 告诉命 令重新 应用被 暂存的 变更。 如果你 
是这么 做的， 你应 该已经 回到你 原来的 位置： 

$ git stash apply ― index 

# On branch master 

# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 

# 

# modified: index.html 
# 

# Changes not staged for commit: 

# (use "git add <file>..." to update what will be committed ) 

# 

# modified: lib/simplegit.rb 
# 



apply 选项只 尝试应 用储藏 的工作 —— 储藏 的内容 仍然在 桟上。 要移 除它， 你可 以运行 
git stash drop, 加上 你希望 移除的 储藏的 名字： 

$ git stash list 

stash@{0}: WIP on master: 049d078 added the index file 
stash@{1 }: WIP on master: c264051... Revert "added file— size" 
stash@{2}: WIP on master: 21d80a5... added number to log 
$ git stash drop stash@{0} 

Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43) 

你也可 以运行 git stash pop 来重 新应用 储藏， 同 时立刻 将其从 堆桟中 移走。 
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6.3.2 取 消储藏 （Un-applying a Stash) 
在 某些情 况下， 你可能 想应用 储藏的 修改， 在 进行了 一些其 他的修 改后， 又 要取消 之前所 

应用 储藏的 修改。 Git 没 有提供 类似于 stash unapply 的 命令， 但 是可以 通过取 消该储 藏的补 
丁达到 同样的 效果： 



$ git stash show - p stash@{0} I git apply - R 




同 样的， 如果你 □ 有指 定具体 的某个 储藏， Git 会选择 最近的 储藏: 



$ git stash show - p I git apply — R 




你可能 会想要 新建一 个口 名， 在你的 Git 里增 加一个 stash-unapply 命令， 这样 更有效 
率。 例如： 

$ git config ― global alias. stash-unapply '！ git stash show - p I git apply - FV 
$ git stash 

$ #••• work work work 
$ git stash-unapply 



6.3.3 从储 藏中创 建分支 

如果 你储藏 了一些 工作， 暂 时不去 理会， 然后 继续在 你储藏 工作的 分支上 工作， 你 在重新 
应用工 作时可 能会碰 到一些 问题。 如 果尝试 应用的 变更是 针对一 个你那 之后修 改过的 文件， 
你 会碰到 一个归 并冲突 并且必 须去化 解它。 如果 你想用 更方便 的方法 来重新 检验你 储藏的 

变更， 你可 以运行 git stash branch, 这会 创建一 个新的 分支， 检 出你储 藏工作 时的所 处的提 
交， 重新应 用你的 工作， 如果 成功， 将 会丢弃 储藏。 

$ git stash branch testchanges 
Switched to a new branch "testchanges" 

# On branch testchanges 

# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 
# 

# modified: index.html 
# 

# Changes not staged for commit: 

# (use "git add <file>..." to update what will be committed ) 
# 

# modified: lib/simplegit.rb 



155 



第 6 章 Git 工具 



Scott Chacon Pro Git 



# 

Dropped refs/stash@{0} (f0dfc4d5dc332d1cee34a634182e168c4efc3359) 




这是一 个很棒 的捷径 来恢复 储藏的 工作然 后在新 的分支 上继续 当时的 工作。 



6.4 重 写历史 

很多 时候， 在 Git 上 工作的 时候， 你也许 会由于 某种原 因想要 修订你 的提交 历史。 Git 的 
一 个卓越 之处就 是它允 许你在 最后可 能的时 刻再作 决定。 你可以 在你即 将提交 暂存区 时决定 
什么文 件归入 哪一次 提交， 你可 以使用 stash 命令 来决定 你暂时 搁置的 工作， 你可以 重写已 
经发生 的提交 以使它 们看起 来是另 外一种 样子。 这个包 括改变 提交的 次序、 改 变说明 或者修 
改 提交中 包含的 文件， 将提交 归并、 拆分 或者完 全删除 —— 这一 切在你 尚未开 始将你 的工作 
和别人 共享前 都是可 以的。 

在这一 节中， 你会学 到如何 完成这 些很有 用的任 务以使 你的提 交历史 在你将 其共享 给别人 
之前 变成你 想要的 样子。 

6.4.1 改变 最近一 次提交 

改变 最近一 次提交 也许是 最常见 的重写 历史的 行为。 对于 你的最 近一次 提交， 你经 常想做 
两 件基本 事情： 改 变提交 说明， 或者改 变你刚 刚通过 增加， 改变， 删除而 记录的 快照。 
如 果你只 想修改 最近一 次提交 说明， 这非常 简单： 



$ git commit ― amend 



这会把 你带入 文本编 辑器， 里面包 含了你 最近一 次提交 说明， 供你 修改。 当 你保存 并退出 
编 辑器， 这个编 辑器会 写入一 个新的 提交， 里 面包含 了那个 说明， 并且 让它成 为你的 新的最 
近一次 提交。 

如 果你完 成提交 后又想 修改被 提交的 快照， 增加或 者修改 其中的 文件， 可能 因为你 最初提 

交时， 忘了添 加一个 新建的 文件， 这 个过程 基本上 一样。 你 通过修 改文件 然后对 其运行 git 
add 或 对一个 已被记 录的文 件运行 git rm, 随后的 git commit -amend 会获 取你当 前的暂 存区并 
将 它作为 新提交 对应的 快照。 

使用这 项技术 的时候 你必须 小心， 因 为修正 会改变 提交的 SHA-1 值。 这个 很像是 一次非 
常小的 rebase —— 不要 在你最 近一次 提交被 推送后 还去修 正它。 

6.4.2 修改 多个提 交说明 

要修改 历史中 更早的 提交， 你必须 采用更 复杂的 工具。 Git 没有一 个修改 历史的 工具， 但 
是你可 以使用 rebase 工具 来衍合 一系 列的提 交到它 们原来 所在的 HEAD 上而 不是移 到新的 
上。 依靠 这个交 互式的 rebase 工具， 你就 可以停 留在每 一次提 交后， 如果你 想修改 或改变 
说明、 增加文 件或任 何其他 事情。 你可以 通过给 git rebase 增加 -i 选项 来以交 互方式 地运行 
rebase. 你必 须通过 告诉命 令衍合 到哪次 提交， 来指 明你需 要重写 的提交 的回溯 深度。 

例如， 你想 修改最 近三次 的提交 说明， 或者其 中任意 一次， 你 必须给 git rebase -i 提 供一个 
参数， 指明你 想要修 改的提 交的父 提交， 例如 HEAD~2 或者 HEAD~3。 可能 记住〜 3 更加 容易， 
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因 为你想 修改最 近三次 提交； 但是 请记住 你事实 上所指 的是四 次提交 之前， 即 你想修 改的提 
交的父 提交。 



$ git rebase -i HEAD-3 




再次提 醒这是 一个衍 合命令 —— HEAD~3..HEAD 范围内 的每一 次提交 都会被 重写， 无论你 
是否修 改说明 。 不要涵 盖你已 经推送 到中心 服务器 的提交 —— 这 么做会 使其他 开发者 产生混 
乱， 因 为你提 供了同 样变更 的不同 版本。 

运行这 个命令 会为你 的文本 编辑器 提供一 个提交 列表， 看起 来像下 面这样 

pick f7f3f6d changed my name a bit 

pick 310154e updated README formatting and added blame 
pick a5f4a0d added cat-file 

# Rebase 710f0f8..a5f4a0d onto 71 Of Of 8 
# 

# Commands: 

# p， pick = use commit 

# e， edit = use commit, but stop for amending 

# s， squash = use commit, but meld into previous commit 

# 

# If you remove a line here THAT COMMIT WILL BE LOST. 

# However, if you remove everything, the rebase will be aborted. 
# 



很重要 的一点 是你得 注意这 些提交 的顺序 与你通 常通过 log 命 令看到 的是相 反的。 如果你 
运行 log, 你会看 到下面 这样的 结果： 

$ git log — pretty=format: M %h %s" HEAD-3..HEAD 
a5f4a0d added cat-file 

310154e updated README formatting and added blame 
f7f3f6d changed my name a bit 



请注意 这里的 倒序。 交 互式的 rebase 给 了你一 个即将 运行的 脚本。 它会从 你在命 令行上 
指 明的提 交开始 (HEAD~3) 然后 自上 至下重 播每次 提交里 引入的 变更。 它将最 早的列 在顶上 
而 不是最 近的， 因 为这是 第一个 需要重 播的。 

你需要 修改这 个脚本 来让它 停留在 你想修 改的变 更上。 要 做到这 一点， 你只 要将你 想修改 
的每一 次提交 前面的 pick 改为 edit。 例如， 只想 修改第 三次提 交说明 的话， 你 就像下 面这样 
修改 文件： 
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edit f7f3f6d changed my name a bit 

pick 310154e updated README formatting and added blame 
pick a5f4a0d added cat-file 



当你 保存并 退出编 辑器， Git 会倒回 至列表 中的最 后一次 提交， 然后 把你送 到命令 行中， 
同时显 示以下 信息： 

$ git rebase - i HEAD-3 

Stopped at 7482e0d... updated the gemspec to hopefully work better 
You can amend the commit now, with 

git commit ― amend 

Once you' re satisfied with your changes, run 

git rebase -- continue 

这些 指示很 明确地 告诉了 你该干 什么。 输入 



$ git commit ― amend 




修 改提交 说明， 退出编 辑器。 然后， 运行 



$ git rebase ― continue 



这 个命令 会自动 应用其 他两次 提交， 你就 完成任 务了。 如果 你将更 多行的 pick 改为 edit 

, 你就能 对你想 修改的 提交重 复这些 步骤。 Git 每 次都会 停下， 让 你修正 提交， 完成 后继续 

运行。 

6.4.3 重 排提交 

你也 可以使 用交互 式的衍 合来彻 底重排 或删除 提交。 如果你 想删除 "added cat-file" 这 
个 提交并 且修改 其他两 次提交 引入的 顺序， 你将 rebase 脚本 从这个 

pick f7f3f6d changed my name a bit 

pick 310154e updated README formatting and added blame 
pick a5f4a0d added cat-file 
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改为 这个: 



pick 310154e updated README formatting and added blame 
pick f7f3f6d changed my name a bit 




当你 保存并 退出编 辑器， Git 将分支 倒回至 这些提 交的父 提交， 应用 310154e, 然后 f7f3f6d， 
接着 停止。 你有效 地修改 了这些 提交的 顺序并 且彻底 删除了 "added cat-file" 这次 提交。 

6.4.4 压制 （Squashing) 提交 

交 互式的 衍合工 具还可 以将一 系列提 交压制 为单一 提交。 脚本在 rebase 的 信息里 放了一 
些 有用的 指示： 

# 

# Commands: 

# p， pick = use commit 

# e， edit = use commit, but stop for amending 

# s， squash = use commit, but meld into previous commit 
# 

# If you remove a line here THAT COMMIT WILL BE LOST. 

# However, if you remove everything, the rebase will be aborted. 
# 



如 果不用 "pick" 或者 "edit" , 而 是指定 "squash" ， Git 会同时 应用那 个变更 和它之 
前 的变更 并将提 交说明 归并。 因此， 如果你 想将这 三个提 交合并 为单一 提交， 你可以 将脚本 
修改成 这样： 

pick f7f3f6d changed my name a bit 

squash 310154e updated README formatting and added blame 
squash a5f4a0d added cat-file 



当你 保存并 退出编 辑器， Git 会应 用全部 三次变 更然后 将你送 回编辑 器来归 并三次 提交说 

明。 

# This is a combination of 3 commits. 

# The first commit' s message is: 
changed my name a bit 

# This is the 2nd commit message: 
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updated README formatting and added blame 
# This is the 3rd commit message: 
added cat-file 



当 你保存 之后， 你 就拥有 了一个 包含前 三次提 交的全 部变更 的单一 提交。 

6.4.5 拆 分提交 

拆 分提交 就是撤 销一次 提交， 然后 多次部 分地暂 存或提 交直到 结束。 例如， 假设你 想将三 
次提交 中的中 间一次 拆分。 将 "updated README formatting and added blame" 拆分成 
两次 提交： 第一 次为 "updated README formatting" , 第 二次为 "added blame" 。 你 
可以在 rebase -i 脚本 中修改 你想拆 分的提 交前的 指令为 "edit" ： 

pick f7f3f6d changed my name a bit 

edit 310154e updated README formatting and added blame 
pick a5f4a0d added cat-file 

然后， 这 个脚本 就将你 带入命 令行， 你重 置那次 提交， 提取被 重置的 变更， 从中 创建多 
次 提交。 当你 保存并 退出编 辑器， Git 倒 回到列 表中第 一次提 交的父 提交， 应用第 一次提 
交 （f7f3f6d)， 应 用第二 次提交 （310154e) ， 然 后将你 带到控 制台。 那里你 可以用 git reset 
HEADD 对那次 提交进 行一次 混合的 重置， 这 将撤销 那次提 交并且 将修改 的文件 撤回。 此时 
你可 以暂存 并提交 文件， 直 到你拥 有多次 提交， 结 束后， 运行 git rebase -continue 

$ git reset HEAD A 
$ git add README 

$ git commit -m 'updated README formatting' 

$ git add lib/simplegit.rb 

$ git commit -m 'added blame' 

$ git rebase ― continue 



Git 在 脚本中 应用了 最后一 次提交 （a5f4a0d) ， 你 的历史 看起来 就像这 样了： 

$ git log —4 — pretty=format:"%h %s" 

1c002dd added cat-file 

9b29157 added blame 

35cfb2b updated README formatting 

f3cc40e changed my name a bit 

再次 提醒， 这会修 改你列 表中的 提交的 SHA 值， 所以 请确保 这个列 表里不 包含你 已经推 
送 到共享 仓库的 提交。 
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6.4.6 核弹级 选项： filter-branch 
如果你 想用脚 本的方 式修改 大量的 提交， 还有 一个重 写历史 的选项 可以用 —— 例如， 全局 

性地 修改电 子邮件 地址或 者将一 个文件 从所有 提交中 删除。 这个 命令是 filter-branch, 这个会 
大面 积地修 改你的 历史， 所 以你很 有可能 不该去 用它， 除非 你的项 目尚未 公开， 没有 其他人 
在 你准备 修改的 提交的 基础上 工作。 尽管 如此， 这个可 以非常 有用。 你会学 习一些 常见用 
法， 借此对 它的能 力有所 认识。 

从所有 提交中 删除一 个文件 

这 个经常 发生。 有些人 不经思 考使用 git add ., 意外 地提交 了一个 巨大的 二进制 文件， 
你想将 它从所 有地方 删除。 也 许你不 小心提 交了一 个包含 密码的 文件， 而 你想让 你的项 
目 开源。 filter-branch 大概 会是你 用来清 理整个 历史的 工具。 要 从整个 历史中 删除一 个名叫 
password.txt 的文 件， 你可以 在 filter-branch 上使 用一一 tree-filter 选 I 页： 

$ git filter-branch 一一 tree-filter 'rm — f passwords.txt' HEAD 
Rewrite 6b9b3cf04e7c5686a9cb838c3f36a8cb6a0fc2bd (21/21) 
Ref 'refs/heads/master' was rewritten 



—tree-filter 选 项会在 每次检 出项目 时先执 行指定 的命令 然后重 新提交 结果。 在这 个例子 
中， 你会 在所有 快照中 删除一 个名叫 password.txt 的 文件， 无论 它是否 存在。 如果 你想删 
除 所有不 小心提 交上去 的编辑 器备份 文件， 你 可以运 行类似 git filter-branch -tree-filter 'rm -f 
*~' HEAD 的 命令。 

你可以 观察到 Git 重 写目录 树并且 提交， 然后将 分支指 针移到 末尾。 一个比 较好的 办法是 
在一 个测试 分支上 做这些 然后在 你确定 产物真 的是你 所要的 之后， 再 hard-reset 你 的主分 
支。 要在 你所有 的分支 上运行 filter-branch 的活， 你可以 传递一 个 一all 给 命令。 

将 一个子 目 录 设置为 新的根 目 录 

假设 你完成 了从另 外一个 代码控 制系统 的导入 工作， 得 到了一 些没有 意义的 子目录 
(trunk, tags 等等 ） 。 如果 你想让 tmnk 子 目录成 为每一 次提交 的新的 项目根 目录， filter- 
bmnch 也可 以帮你 做到： 

$ git filter-branch 一一 subdirectory-filter trunk HEAD 
Rewrite 856f0bf61e41a27326cdae8f09fe708d679f596f (12/12) 
Ref 'refs/heads/master' was rewritten 



现在 你的项 目根目 录就是 tamk 子目 录了。 Git 会 自动地 删除不 对这个 子目录 产生影 晌的提 

交。 

全局性 地更换 电子邮 件地址 

另一个 常见的 案例是 你在开 始时忘 了运行 git config 来设置 你的姓 名和电 子邮件 地址， 也许 
你 想开源 一个项 目 ， 把你所 有的工 作电子 邮件地 址修改 为个人 地址。 无 论哪种 情况你 都可以 
用 filter-branch 来 更换多 次提交 里的电 子邮件 地址。 你必 须小心 一些， 只 改变属 于你的 电子邮 
件 地址， 所以 你使用 一commit- filter: 
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$ git filter-branch ― commit— filter ' 

if [ "$GIT— AUTHOR— EMAIL" = "schacon@localhost" ]; 
then 

GIT— AUTHOR— NAME="Scott Chacon"; 

GIT— AUTHOR — EMAIL="schacon@example.com' 

git commit-tree "$@"; 

else 

git commit-tree "$@"; 
fi' HEAD 



这 个会遍 历并重 写所有 提交使 之拥有 你的新 地址。 因为提 交里包 含了它 们的父 提交的 
SHA-1 值， 这个命 令会修 改你的 历史中 的所有 提交， 而 不仅仅 是包含 了匹配 的电子 邮件地 
址的 那些。 



6.5 使用 Git 调试 

Git 同样提 供了一 些工具 来帮助 你调试 项目中 遇到的 问题。 由于 Git 被设计 为可应 用于几 
乎任何 类型的 项目， 这些工 具是通 用型， 但 是在遇 到问题 时可以 经常帮 助你查 找缺陷 所在。 

6.5.1 文 件标注 

如果你 在追踪 代码中 的缺陷 想知道 这是什 么时候 为什么 被引进 来的， 文件标 注会是 你的最 
佳 工具。 它会 显示文 件中对 每一行 进行修 改的最 近一次 提交。 因此， 如 果你发 现自己 代码中 

的 一个方 法存在 缺陷， 你 可以用 git blame 来标注 文件， 查 看那个 方法的 每一行 分别是 由谁在 
哪 一天修 改的。 下面这 个例子 使用了 -L 选项 来限制 输出范 围在第 12 至 22 行： 

$ git blame -L 12,22 simplegit.rb 

A 4832fe2 {Scott Chacon 2008-03-15 10:31:28 -0700 12) def showftree = 'master') 
A 4832fe2 {Scott Chacon 2008-03-15 10:31:28 - 0700 13) command {"git show #{tree}") 
A 4832fe2 (Scott Chacon 2008-03-15 10:31:28 - 0700 14) end 
A 4832fe2 (Scott Chacon 2008-03-15 10:31:28 -0700 15) 

9f6560e4 (Scott Chacon 2008-03-17 21:52:20 - 0700 16) def log(tree = 'master') 

79eaf55d (Scott Chacon 2008-04-06 10:15:08 -0700 17) commandC'git log #{tree}") 

9f6560e4 (Scott Chacon 2008-03-17 21:52:20 - 0700 18) end 

9f6560e4 (Scott Chacon 2008-03-17 21:52:20 -0700 19) 

42cf2861 (Magnus Chacon 2008-04-13 10:45:01 - 0700 20) def blame(path) 

42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 21) command ("git blame #{path}" 

42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 22) end 



请注 意第一 个域里 是最后 一次修 改该行 的那次 提交的 SHA-1 值。 接 下去的 两个域 是从那 
次提 交中抽 取的值 —— 作 者姓名 和日期 —— 所以你 可以方 便地获 知谁在 什么时 候修改 了这一 
行。 在这 后面是 行号和 文件的 内容。 请注意 口4832^2 提 交的那 些行， 这 些指的 是文件 最初提 
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交的那 些行。 那 个提交 是文件 第一次 被加入 这个项 目时存 在的， 自 那以后 未被修 改过。 这会 
带来 小小的 困惑， 因 为你已 经至少 看到了 Git 使用 口来修 饰一个 提交的 SHA 值 的三种 不同的 
意义， 但这里 确实就 是这个 意思。 

另 一件很 酷的事 情是在 Git 中你 不需要 显式地 记录文 件的重 命名。 它 会记录 快照然 
后根据 现实尝 试找出 隐式的 重命名 动作。 这 其中有 一个很 有意思 的特性 就是你 可以让 
它找 出所有 的代码 移动。 如 果你在 git blame 后加上 -C, Git 会 分析你 在标注 的文件 然后尝 
试找出 其中代 码片段 的原始 出处， 如 果它是 从其他 地方拷 贝过来 的活。 最近， 我 在将一 
个名叫 GITServerHandler.m 的文件 分解到 多个文 件中， 其中 I s " 是 GITPackUpload.m。 通过 
对 GITPackUpload.m 执行带 -C 参数的 blame 命令， 我可 以看到 代码块 的原始 出处： 



$ git blame -C - L 141,153 GITPackUpload.m 




f344f58d GITServerHandler.m 


(Scott 2009-01-04 141) 




f344f58d GITServerHandler.m 


(Scott 2009-01-04 142) - ( 


void) gatherObjectShasFromC 


f344f58d GITServerHandler.m 


(Scott 2009-01-04 143) { 




70befddd GITServerHandler.r 


n (Scott 2009-03-22 144) 


//NSLog (©"GATHER COMMI 


ad11ac80 GITPackUpload.m 


(Scott 2009-03-24 145) 




ad11ac80 GITPackUpload.m 


(Scott 2009-03-24 146) 


NSString *parentSha; 


ad11ac80 GITPackUpload.m 


(Scott 2009-03-24 147) 


GITCommit *commit = [g 


ad11ac80 GITPackUpload.m 


(Scott 2009-03-24 148) 




ad11ac80 GITPackUpload.m 


(Scott 2009-03-24 149) 


//NSLog{@"GATHER COMMI 


ad11ac80 GITPackUpload.m 


(Scott 2009-03-24 150) 




56ef2caf GITServerHandler.m 


(Scott 2009-01-05 151) 


if {commit) { 


56ef2caf GITServerHandler.m 


(Scott 2009-01-05 152) 


[refDict setOb 


56ef2caf GITServerHandler.m 


(Scott 2009-01-05 153) 





这真 的非常 有用。 通常， 你会 把你拷 贝代码 的那次 提交作 为原始 提交， 因为 这是你 在这个 

文 件中第 一次接 触到那 几行。 Git 可 以告诉 你编写 那些行 的原始 提交， 即便是 在另一 个文件 

里。 

6.5.2 二 分查找 

标注 文件在 你知道 问题是 哪里引 入的时 候会有 帮助。 如 果你不 知道， 并且自 上次代 码可用 

的状态 已经经 历了上 百次的 提交， 你可 能就要 求助于 bisect 命 令了。 bisect 会在 你的提 交历史 
中进行 二分查 找来尽 快地确 定哪一 次提交 引入了 错误。 

例如 你刚刚 推送了 一个代 码发布 版本到 产品环 境中， 对代码 为什么 会表现 成那样 百思不 
得 其解。 你回到 你的代 码中， 还好你 可以重 现那个 问题， 但是找 不到在 哪里。 你可 以对代 
码执行 bisect 来 寻找。 首先 你运行 git bisect start 启动， 然 后你用 git bisect bad 来 告诉系 统当前 
的 提交已 经有问 题了。 然 后你必 须告诉 bisect 已知 的最后 一次正 常状态 是哪次 提交， 使用 git 
bisect good [good— commit]: 

$ git bisect start 
$ git bisect bad 
$ git bisect good v1.0 
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Bisecting: 6 revisions left to test after this 

[ecb6e1bc347ccecc5f9350d878ce677feb13d3b2] error handling on repo 




Git 发现在 你标记 为正常 的提交 (v1.0) 和 当前的 错误版 本之间 有大约 12 次 提交， 于 是它检 
出 中间的 一个。 在 这里， 你 可以运 行测试 来检查 问题是 否存在 于这次 提交。 如 果是， 那么它 
是在这 个中间 提交之 前的某 一次引 入的； 如 果否， 那 么问题 是在中 间提交 之后引 入的。 假设 
这里是 没有错 误的， 那么你 就通过 git bisect good 来告诉 Git 然后继 续你的 旅程： 

$ git bisect good 

Bisecting: 3 revisions left to test after this 

[b047b02ea83310a70fd603dc8cd7a6cd13d15c04] secure this thing 

现 在你在 另外一 个提交 上了， 在你刚 刚测试 通过的 和一个 错误提 交的中 点处。 你再 次运行 
测试然 后发现 这次提 交是错 误的， 因此 你通过 git bisect bad 来告诉 Git: 

$ git bisect bad 

Bisecting: 1 revisions left to test after this 

[f71ce38690acf49df3c9bea38e09d82a5ce6014] drop exceptions table 



这次 提交是 好的， 那么 Git 就获 得了确 定问题 引入位 置所需 的所有 信息。 它 告诉你 第一个 
错误 提交的 SHA-1 值并且 显示一 些提交 说明以 及哪些 文件在 那次提 交里修 改过， 这 样你可 
以找出 缺陷被 引入的 根源： 

$ git bisect good 

b047b02ea83310a70fd603dc8cd7a6cd13d15c04 is first bad commit 
commit b047b02ea83310a70fd603dc8cd7a6cd13d15c04 
Author: PJ Hyett <pjhyett@example.com> 
Date: Tue Jan 27 14:48:32 2009 -0800 

secure this thing 

:040000 040000 40ee3e7821b895e52c1695092db9bdc4c61d1730 
f24d3c6ebcfc639b1a3814550e62d60b8e68a8e4 M config 



当 你完成 之后， 你应 该运行 git bisect reset 来重 设你的 HEAD 到你开 始前的 地方， 否 则你会 
处 于一个 诡异的 地方： 

$ git bisect reset 
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这是个 强大的 工具， 可 以帮助 你检查 上百的 提交， 在几分 钟内找 出缺陷 引入的 位置。 事 
实上， 如果 你有一 个脚本 会在工 程正常 时返回 0, 错误时 返回非 0 的活， 你可 以完全 自动地 
执行 gitbi sec t。 首先 你需要 提供已 知的错 误和正 确提交 来告诉 它二分 查找的 范围。 你 可以通 
过 bisect start 命令 来列出 它们， 先列出 已知的 错误提 交再列 出已知 的正确 提交： 

$ git bisect start HEAD v1.0 
$ git bisect run test-error.sh 



这样会 自动地 在每一 个检出 的提交 里运行 test-ew.sh 直到 Git 找出 第一个 破损的 提交。 你 
也可以 运行像 make 或者 make tests 或者任 何你所 拥有的 来为你 执行自 动化的 测试。 



6.6 子模块 

经常有 这样的 事情， 当你在 一个项 目上工 作时， 你需要 在其中 使用另 外一个 项目。 也许它 
是 一个第 三方开 发的库 或者是 你独立 开发和 并在多 个父项 目中使 用的。 这个场 景下一 个常见 
的 问题产 生了： 你想 将两个 项目单 独处理 但是又 需要在 其中一 个中使 用另外 一个。 

这里有 一个 例子。 假设 你在开 发一个 网站， 为 之创建 Atom 源。 你不想 编写一 个 自己的 
Atom 生成 代码， 而 是决定 使用一 个库。 你 可能不 得不像 CPAN install 或者 Ruby gem— 样 
包含 来自共 享库的 代码， 或者将 代码拷 贝到你 的项目 树中。 如果 采用包 含库的 办法， 那么不 
管 用什么 办法都 很难去 定制这 个库， 部 署它就 更加困 难了， 因为 你必须 确保每 个客户 都拥有 
那 个库。 把代 码包含 到你自 己的项 目中带 来的问 题是， 当上 游被修 改时， 任何 你进行 的定制 
化 的修改 都很难 归并。 

Git 通过子 模块处 理这个 问题。 子模块 允许你 将一个 Git 仓库 当作另 外一个 Git 仓 库的子 
目录。 这 允许你 克隆另 外一个 仓库到 你的项 目中并 且保持 你的提 交相对 独立。 

6.6.1 子模 块初步 

假设 你想把 Rack 库 （ 一个 Ruby 的 web 服 务器网 关接口 ） 加入到 你的项 目中， 可能既 
要 保持你 自己的 变更， 又 要延续 上游的 变更。 首先 你要把 外部的 仓库克 隆到你 的子目 录中。 
你通过 git submodule add 将外 部项目 加为子 模块： 

$ git submodule add git://g ithub.com/chneukirchen/ rack. git rack 

Initialized empty Git repository in /opt/subtest/rack/.git/ 

remote: Counting objects: 3181, done. 

remote: Compressing objects: 100% (1534/1534), done. 

remote: Total 3181 (delta 1951), reused 2623 (delta 1603) 

Receiving objects: 100% (3181/3181), 675.42 KiB I 422 KiB/s, done. 

Resolving deltas: 100% (1951/1951), done. 



现在你 就在项 目里的 rack 子目 录下有 了一个 Rack 项目。 你可 以进入 那个子 目录， 进行变 
更， 加入 你自己 的远程 可写仓 库来推 送你的 变更， 从 原始仓 库拉取 和归并 等等。 如果 你在加 
入子模 块后立 刻运行 git status, 你会看 到下面 两项： 
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$ git status 




# On branch master 




# Changes to be committed: 




# (use "git reset HEAD <file>..." to u 


nstage) 


# 




# new file: .gitmodules 




# new file: rack 




# 





首 先你注 意到有 一个. gitmodules 文件。 这是一 个配置 文件， 保存 了项目 URL 和你 拉取到 
的本地 子目录 



$ cat .gitmodules 
[submodule "rack"] 
path = rack 

url = git://g ithub.com/chneukirch en/ rack. git 



如 果你有 多个子 模块， 这个文 件里会 有多个 条目。 很重 要的一 点是这 个文件 跟其他 文件一 

样 也是处 于版本 控制之 下的， 就像 你的. gitignore 文件 一样。 它跟 项目里 的其他 文件一 样可以 
被 推送和 拉取。 这是其 他克隆 此项目 的人获 知子模 块项目 来源的 途径。 

git status 的输出 里所列 的另一 项目是 rack 。 如果 你运行 在那上 面运行 git diff, 会发 现一些 
有趣的 东西： 

$ git diff -- cached rack 
diff -- git a/ rack b/ rack 
new file mode 160000 
index 0000000..08d709f 
— /dev/null 
+++ b/rack 
@@ -o,0 +1 @@ 

+Subproject commit 08d709f78b8c5b0fbeb7821e37fa53e69afcf433 



尽管 rack 是你工 作目录 里的子 目录， 但 Git 把它 视作一 个子 模块， 当 你不在 那个目 录里时 
并不记 录它的 内容。 取 而代之 的是， Git 将它 记录成 来自那 个仓库 的一个 特殊的 提交。 当你 
在那 个子目 录里修 改并提 交时， 子项目 会通知 那里的 HEAD 已 经发生 变更并 记录你 当前正 
在工作 的那个 提交； 通过 那样的 方法， 当 其他人 克隆此 项目， 他们可 以重新 创建一 致的环 

境。 

这 是关于 子模块 的重要 一点： 你记录 他们当 前确切 所处的 提交。 你 不能记 录一个 子模块 
的 master 或 者其他 的符号 引用。 

当你提 交时， 会看到 类似下 面的： 
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$ git commit -m 'first commit with submodule rack' 
[master 0550271] first commit with submodule rack 

2 files changed, 4 insertions( + ), 0 deletions (-) 

create mode 100644 .gitmodules 

create mode 160000 rack 

注意 rack 条目的 160000 模式。 这在 Git 中是一 个特殊 模式， 基本意 思是你 将一个 提交记 
录 为一个 目 录项而 不是子 目 录或者 文件。 

你 可以将 rack 目录当 怍一个 独立的 项目， 保持一 个指向 子目录 的最新 提交的 指针然 后反复 
地更新 上层项 目 。 所有的 G it 命 令都在 两个子 目 录 里独立 工作： 

$ git log -1 

commit 0550271328a0038865aad6331e620cd7238601bb 
Author: Scott Chacon <schacon@gmail.com> 
Date: Thu Apr 9 09:03:56 2009 -0700 

first commit with submodule rack 
$ cd rack/ 
$ git log -1 

commit 08d709f78b8c5b0fbeb7821e37fa53e69afcf433 
Author: Christian Neukirchen <chneukirchen@gmail.com> 
Date: Wed Mar 25 14:49:04 2009 +0100 

Document version change 



6.6.2 克隆 一个带 子模块 的项目 

这 里你将 克隆一 个带子 模块的 项目。 当你接 收到这 样一个 项目， 你将 得到了 包含子 项目的 
目录， 但里 面没有 文件： 

$ git clone git://g ithub.com/schacon/myproject.git 

Initialized empty Git repository in /opt/myproject/.git/ 

remote: Counting objects: 6， done. 

remote: Compressing objects: 100% (4/4)， done. 

remote: Total 6 (delta 0), reused 0 (delta 0) 

Receiving objects: 100% (6/6), done. 

$ cd myproject 

$ Is -I 

total 8 

-rw-r-r— 1 schacon admin 3 Apr 9 09:11 README 
drwxr-xr-x 2 schacon admin 68 Apr 9 09:1 1 rack 
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$ Is rack/ 
$ 




rack 目录存 在了， 但是是 空的。 你 必须运 行两个 命令： git submodule init 来初 始化你 的本地 
配置 文件， git submodule update 来从 那个项 目拉取 所有数 据并检 出你上 层项目 里所列 的合适 
的 提交： 

$ git submodule init 

Submodule 'rack' (git://g ithub.com/chneukirchen/ rack. git) registered for path 'rack' 
$ git submodule update 

Initialized empty Git repository in / opt/ my project/ rack/.git/ 

remote: Counting objects: 3181, done. 

remote: Compressing objects: 100% (1534/1534), done. 

remote: Total 3181 (delta 1951), reused 2623 (delta 1603) 

Receiving objects: 100% (3181/3181), 675.42 KiB I 173 KiB/s, done. 

Resolving deltas: 100% (1951/1951), done. 

Submodule path 'rack': checked out '08d709f78b8c5b0fbeb7821e37fa53e69afcf433 / 



现 在你的 mck 子目录 就处于 你先前 提交的 确切状 态了。 如果另 外一个 开发者 变更了 rac k 
的 代码并 提交， 你 拉取那 个引用 然后归 并之， 将得到 稍有点 怪异的 东西： 

$ git merge origin/ master 
Updating 0550271..85a3eee 
Fast forward 
rack I 2 +- 

1 files changed, 1 insertions( + ), 1 deletions ( — ) 
[master*]$ git status 

# On branch master 

# Changes not staged for commit: 

# (use "git add <file>..." to update what will be committed ) 

# (use "git checkout 一一 <file>..." to discard changes in working directory) 

# 

# modified: rack 
# 



你 归并来 的仅仅 上是一 个指向 你的子 模块的 指针； 但 是它并 不更新 你子模 块目录 里的代 
码， 所以 看起来 你的工 作目录 处于一 个临时 状态： 

$ git diff 

diff -- git a/rack b/ rack 
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index 6c5e70b..08d709f 160000 
— a/rack 
+++ b/rack 
@@ -1 +1 @@ 

-Subproject commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0 
+Subproject commit 08d709f78b8c5b0fbeb7821e37fa53e69afcf433 



事 情就是 这样， 因 为你所 拥有的 指向子 模块的 指针和 子模块 目录的 真实状 态并不 匹配。 为 
了 修复这 一点， 你必 须再 次运行 git submodule update: 

$ git submodule update 

remote: Counting objects: 5, done. 

remote: Compressing objects: 100% (3/3)， done. 

remote: Total 3 (delta 1), reused 2 (delta 0) 

Unpacking objects: 100% (3/3)， done. 

From git@github.com:schacon/ rack 

08d709f..6c5e70b master -> origin/ master 
Submodule path 'rack': checked out / 6c5e70b984a60b3cecd395edd5b48a7575bf58e0 / 



每次你 从主项 目 中拉取 一个子 模块的 变更都 必须这 样做。 看 起来很 怪但是 管用。 
一个 常见问 题是当 开发者 对子模 块做了 一个本 地的变 更但是 并没有 推送到 公共服 务器。 然 
后他 们提交 了一个 指向那 个非公 开状态 的指针 然后推 送上层 项目。 当 其他开 发者试 图运行 git 
submodule update, 那个子 模块系 统会找 不到所 引用的 提交， 因 为它只 存在于 第一个 开发者 
的系 统中。 如果发 生那种 情况， 你会看 到类似 这样的 错误： 

$ git submodule update 

fatal: reference isn' t a tree: 6c5e70b984a60b3cecd395edd5b48a7575bf58e0 

Unable to checkout / 6c5e70b984a60b3cecd395edd5ba7575bf58e0 / in submodule path 'rack' 



你 不得不 去查看 谁最后 变更了 子模块 

$ git log -1 rack 

commit 85a3eee996800fcfa91e21 19372dd4172bf76678 
Author: Scott Chacon <schacon@gmail.com> 
Date: Thu Apr 9 09:19:14 2009 -0700 

added a submodule reference I will never make public, hahahahaha! 



然后， 你 给那个 家伙发 电子邮 件说他 一通。 
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6.6.3 上 层项目 

有 时候， 开发 者想按 照他们 的分组 获取一 个大项 目的子 目录的 子集。 如果 你是从 cvs 或 

者 Subversion 迁移过 来的活 这个很 常见， 在那些 系统中 你已经 定义了 一个模 块或者 子目录 
的 集合， 而你想 延续这 种类型 的工作 流程。 

在 Git 中实 现这个 的一个 好办法 是你将 每一个 子目录 都做成 独立的 Git 仓库， 然后 创建一 
个上层 项目的 Git 仓 库包含 多个子 模块。 这 个办法 的一个 优势是 你可以 在上层 项目中 通过标 
签和分 支更为 明确地 定义项 目之间 的关系 。 

6.6.4 子模块 的问题 

使用 子模块 并非没 有任何 缺点。 首先， 你在子 模块目 录中工 作时必 须相对 小心。 当你运 

行 git submodule update, 它会检 出项目 的指定 版本， 但是 不在分 支内。 这叫 做获得 一个分 
离的头 —— 这 意味着 HEAD 文件 直接指 向一次 提交， 而 不是一 个符号 引用。 问题 在于你 
通 常并不 想在一 个分离 的头的 环境下 工作， 因为 太容易 丢失变 更了。 如果 你先执 行了一 
次 submodule update, 然 后在那 个子模 块目录 里不创 建分支 就进行 提交， 然后 再次从 上层项 
目 里运行 git submodule update 同时 不进行 提交， Git 会 毫无提 示地覆 盖你的 变更。 技 术上讲 
你不 会丢失 工作， 但 是你将 失去指 向它的 分支， 因此 会很难 取到。 

为了避 免这个 问题， 当你在 子模块 目录里 工作时 应使用 git checkout -b work 创建 一个分 
支。 当你再 次在子 模块里 更新的 时候， 它仍 然会覆 盖你的 工作， 但是至 少你拥 有一个 可以回 
溯的 指针。 

切换带 有子模 块的分 支同样 也很有 技巧。 如果你 创建一 个新的 分支， 增加了 一个子 模块， 
然后切 换回不 带该子 模块的 分支， 你仍 然会拥 有一个 未被追 踪的子 模块的 目 录 

$ git checkout - b rack 
Switched to a new branch "rack" 

$ git submodule add git@github.com:schacon/ rack. git rack 
Initialized empty Git repository in / opt/ myproj/ rack/.git/ 

Receiving objects: 100% (3184/3184), 677.42 KiB I 34 KiB/s, done. 
Resolving deltas: 100% (1952/1952), done. 
$ git commit -am 'added rack submodule' 
[rack cc49a69] added rack submodule 

2 files changed, 4 insertions( + ), 0 deletions ( — ) 

create mode 100644 .gitmodules 

create mode 160000 rack 
$ git checkout master 
Switched to branch "master" 
$ git status 

# On branch master 

# Untracked files: 

# (use "git add <file>..." to include in what will be committed ) 

# 

# rack/ 
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你将 不得不 将它移 走或者 删除， 这样 的活当 你切换 回去的 时候必 须重新 克隆它 —— 你可能 
会丢 失你未 推送的 本地的 变更或 分支。 

最后 一个需 要引起 注意的 是关于 从子目 录切换 到子模 块的。 如 果你已 经跟踪 了你项 目中的 
一些 文件但 是想把 它们移 到子模 块去， 你必 须非常 小心， 否则 Git 会生你 的气。 假设 你的项 
目中 有一个 子目录 里放了 rack 的 文件， 然 后你想 将它转 换为子 模块。 如果你 删除子 目录然 
后运行 submodule add, Git 会向你 大吼： 



$ rm -Rf rack/ 




$ git submodule add git@github.com:schacon/ rack. git rack 




?ack' already exists in the index 




你必 须先将 rack 目录 撤回。 然后 你才能 加入子 模块： 


$ git rm -r rack 




$ git submodule add git@github.com:schacon/ rack. git rack 




Initialized empty Git repository in /opt/testsub/rack/.git/ 




remote: Counting objects: 3184, done. 




remote: Compressing objects: 100% (1465/1465), done. 




remote: Total 3184 (delta 1952), reused 2770 (delta 1675) 




Receiving objects: 100% (3184/3184), 677.42 KiB I 88 KiB/s, done. 




Resolving deltas: 100% (1952/1952), done. 









现 在假设 你在一 个分支 里那样 做了。 如果 你尝试 切换回 一个仍 然在目 录里保 留那些 文件而 
不是子 模块的 分支时 —— 你 会得到 下面的 错误： 



$ git checkout master 

error: Untracked working tree file 'rack/AUTHORS' would be overwritten by merge. 



你必须 先移除 rack 子 模块的 目 录才 能切换 到不包 含它的 分支: 

$ mv rack /tmp/ 
$ git checkout master 
Switched to branch "master" 
$ Is 

README rack 



然后， 当 你切换 回来， 你会 得到一 个空的 rack 目录。 你可 以运行 git submodule update 重新 
克隆， 也 可以将 /tmp/rack 目 录重新 移回空 目录。 
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6.7 子 树合并 

现 在你已 经看到 了子模 块系统 的麻烦 之处， 让 我们来 看一下 解决相 同问题 的另一 途径。 当 

Git 归 并时， 它 会检查 需要归 并的内 容然后 选择一 个合适 的归并 策略。 如果你 归并的 分支是 
两个， Git 使用一 个_ 递归 _ 策略。 如 果你归 并的分 支超过 两个， Git 采用- 章鱼- 策略。 这些策 
略是 自动选 择的， 因 为递归 策略可 以处理 复杂的 三路归 并情况 —— 比如 多于一 个共同 祖先的 
—— 但是它 只能处 理两个 分支的 归并。 章鱼 归并可 以处理 多个分 支但是 但必须 更加小 心以避 
免冲突 带来的 麻烦， 因 此它被 选中作 为归并 两个以 上分支 的默认 策略。 

实 际上， 你也 可以选 择其他 策略。 其中 的一个 就是- 子树- 归并， 你可 以用它 来处理 子项目 
问题。 这里你 会看到 如何换 用子树 归并的 方法来 实现前 一节里 所做的 rack 的 嵌入。 

子 树归并 的思想 是你拥 有两个 工程， 其中一 个项目 映射到 另外一 个项目 的子目 录中， 反过 
来也 一样。 当你 指定一 个子树 归并， Git 可 以聪明 地探知 其中一 个是另 外一个 的子树 从而实 
现正确 的归并 —— 这相当 神奇。 

首 先你将 Rack 应用加 入到项 目中。 你将 Rack 项 目当作 你项目 中的一 个远程 引用， 然后 
将它检 出到它 自身的 分支： 



$ git remote add rack-remote git@github.com:schacon/ rack. git 

$ git fetch rack-remote 

warning: no common commits 

remote: Counting objects: 3184, done. 

remote: Compressing objects: 100% (1465/1465), done. 

remote: Total 3184 (delta 1952), reused 2770 (delta 1675) 

Receiving objects: 100% (3184/3184), 677.42 KiB I 4 KiB/s, done. 

Resolving deltas: 100% (1952/1952), done. 

From git@github.com:schacon/ rack 

* [new branch] build -> rack- remote/build 

* [new branch] master -> rack-remote/ master 

* [new branch] rack-0.4 -> rack— remote/rack - 0.4 

* [new branch] rack-0.9 -> rack- remote/ rack-0.9 
$ git checkout - b rack-branch rack-remote/master 

Branch rack-branch set up to track remote branch refs/ remotes/ rack-remote/ master. 
Switched to a new branch "rack-branch" 



现在 在你的 mck — branch 分支中 就有了 Rack 项 目的根 目录， 而你 自己的 项目在 master 分支 
中。 如果 你先检 出其中 一个然 后另外 一个， 你 会看到 它们有 不同的 项目根 目录： 



$ Is 

AUTHORS KNOWN-ISSUES Rakefile contrib lib 
COPYING README bin example test 

$ git checkout master 
Switched to branch "master" 
$ Is 

README 
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要将 Rack 项目当 作子目 录拉取 到你的 master 项 目中。 你 可以在 Git 中用 git read-tree 来实 
现。 你 会在第 9 章学到 更多与 read-tree 和它 的朋友 相关的 东西， 当前你 会知道 它读取 一个分 
支 的根目 录树到 当前的 暂存区 和工作 目录。 你只 要切换 回你的 master 分支， 然 后拉取 rack 分 
支到 你主项 目 的 master 分支的 rack 子 目 录： 



$ git read-tree -- prefix=rack/ - u rack-branch 



当你 提交的 时候， 看起来 就像你 在那个 子目录 下拥有 Rack 的文件 —— 就像你 从一个 tarball 
里 拷贝的 一样。 有意思 的是你 可以比 较容易 地归并 其中一 个分支 的变更 到另外 一个。 因此， 
如果 Rack 项目更 新了， 你可 以通过 切换到 那个分 支并执 行拉取 来获得 上游的 变更： 

$ git checkout rack-branch 
$ git pull 



然后， 你 可以将 那些变 更归并 回你的 master 分支。 你可 以使用 git merge -s subtree, 它会 
工作的 很好； 但是 Git 同时会 把历史 归并到 一起， 这 可能不 是你想 要的。 为了 拉取变 更并预 
置提交 说明， 需要在 -s subtree 策略选 项的同 时使用 一squash 和 一no-commit 选项。 

$ git checkout master 

$ git merge -- squash - s subtree ― no-commit rack-branch 
Squash commit ― not updating HEAD 

Automatic merge went well; stopped before committing as requested 

所有 Rack 项目的 变更都 被归并 可以进 行本地 提交。 你 也可以 做相反 的事情 —— 在 你主分 
支的 rack 目录里 进行变 更然后 归并回 rack-branch 分支， 然 后将它 们提交 给维护 者或者 推送到 
上游。 

为 了得到 rack 子目 录和你 rack-branch 分支 的区别 —— 以决定 你是否 需要归 并它们 —— 你不 
能使用 一般的 diff 命令。 而是对 你想比 较的分 支运行 git diff-tree: 



$ git diff-tree 一 p rack-branch 



或者， 为了比 较你的 rack 子 目录和 服务器 上你拉 取时的 master 分支， 你可 以运行 



$ git diff-tree -p rack-remote/master 



6.8 总结 

你已 经看到 了很多 高级的 工具， 允 许你更 加精确 地操控 你的提 交和暂 存区。 当你碰 到问题 
时， 你应该 可以很 容易找 出是哪 个分支 什么时 候由谁 引入了 它们。 如果 你想在 项目中 使用子 
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项目， 你 也已经 学会了 一些方 法来满 足这些 需求。 到此， 你应该 能够完 成日常 里你需 要用命 
令行在 Git 下做的 大部分 事情， 并且感 到比较 顺手。 
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到目前 为止， 我 阐述了 Git 基 本的运 作机制 和使用 方式， 介绍了 Git 提供的 许多工 具来帮 
助你简 单且有 效地使 用它。 在 本章， 我将 会介绍 Git 的 一些重 要的配 置方法 和钩子 机制以 
满足自 定义的 要求。 通 过这些 工具， 它会和 你和公 司或团 队配合 得天衣 无缝。 



7.1 配置 Git 

如 第一章 所言， 用 gitconfig 配置 Git, 要 做的第 一件事 就是设 置名字 和邮箱 地址: 

$ git config 一一 global user. name "John Doe" 

$ git config —- global user. email johndoe@example.com 



从现在 开始， 你 会了解 到一些 类似以 上但更 为有趣 的设置 选项来 自定义 Git。 

先过 一遍第 一章中 提到的 Git 配置 细节。 Git 使用一 系列的 配置文 件来存 储你定 义的偏 

好， 它首先 会查找 /etc/gitconfig 文件， 该文 件含有 对系 统上所 有用户 及他们 所拥有 的仓库 
都 生效的 配置值 （译注 ： gitconfig 是全 局配置 文件） ， 如 果传递 一system 选项给 git config 命 
令， Git 会读 写这个 文件。 

接下来 Git 会查找 每个用 户的〜 /.gitconfig 文件， 你 能传递 一global 选项让 Git 读写该 文件。 
最后 Git 会 查找由 用户定 义的各 个库中 Git 目录 下的配 置文件 （ .git/ COn fig ) , 该文 件中的 
值只对 属主库 有效。 以上 阐述的 三层配 置从一 般到特 殊层层 推进， 如 果定义 的值有 冲突， 
以后 面层中 定义的 为准， 例如： 在. git/config 和 /etc/gitconfig 的较 量中， .git/config 取 得了胜 
利。 虽 然你也 可以直 接手动 编辑这 些配置 文件， 但 是运行 git config 命 令将会 来得简 单些。 

7.1.1 客 户端基 本配置 

Git 能 够识别 的配置 项被分 为了两 大类： 客户端 和服务 器端， 其中大 部分基 于你个 人工作 
偏好， 属于 客户端 配置。 尽 管有数 不尽的 选项， 但我 只阐述 其 中经常 使用或 者会对 你的工 
作流产 生巨大 影晌的 选项， 如 果你想 观察你 当前的 Git 能识别 的选项 列表， 请运行 



$ git config ― help 
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gitconfig 的 手册页 （译注 ： 以 man 命令的 显示 方式） 非常细 致地罗 列了所 有可用 的配置 

项。 

core. editor 

Git 默认 会调用 你的环 境变量 editor 定义的 值作为 文本编 辑器， 如果没 有定义 的活， 会调 
用 Vi 来创建 和编辑 提交以 及标签 信息， 你可 以使用 core.editor "改变 默认编 辑器： 

$ git config ― global core. editor emacs 



现 在无论 你的环 境变量 editor 被 定义成 什么， Git 都 会调用 Emacs 编辑 信息。 
commit.template 

如果把 此项指 定为你 系统上 的一个 文件， 当你 提交的 时候， Git 会默 认使用 该文件 定义的 
内容。 例如： 你创 建了一 个模 板文件 SHOME/.gitmessage.txt, 它看 起来像 这样： 

subject line 
what happened 
[ticket: X] 



设置 commiuemplate, 当运行 git commit 时， Git 会 在你的 编辑器 中显示 以上的 内容， 设 
置 commit.template 如下： 

$ git config ― global commit.template $HOME/.gitmessage.txt 
$ git commit 



然后 当你提 交时， 在编辑 器中显 示的提 交信息 如下： 

subject line 
what happened 
[ticket: X] 

# Please enter the commit message for your changes. Lines starting 

# with will be ignored, and an empty message aborts the commit. 

# On branch master 

# Changes to be committed: 

# (use "git reset HEAD <file>..." to unstage) 
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# 

# modified: lib/test.rb 

# 

M .git/COMMIT_EDITMSG" 14L, 297C 



如 果你有 特定的 策略要 运用在 提交信 息上， 在 系统上 创建一 个模板 文件， 设置 Git 默认使 
用它， 这 样当提 交时， 你的策 略每次 都会被 运用。 



core. pager 

core.pager 指定 Git 运 行诸如 log、 diff 等所使 用的分 页器， 你能设 置成用 more 或者 任何你 
喜欢的 分页器 （ 默认 用的是 less ) , 当然你 也可以 什么都 不用， 设 置空字 符串： 



$ git config ― global core.pager 



这 样不管 命令的 输出量 多少， 都会在 一页显 示所有 内容。 

user.signingkey 

如 果你要 创建经 签署的 含附注 的标签 （正如 第二章 所述） ， 那么 把你的 GPG 签署 密钥设 
置为配 置项会 更好， 设 置密钥 ID 如下： 

$ git config ― global user.signingkey <gpg-key-id> 



现 在你能 够签署 标签， 从而 不必每 次运行 git tag 命令 时定义 密钥: 

$ git tag 一 s <tag-name> 



core.excludesfile 

正如 第二章 所述， 你能 在项目 库的. gitignore 文 件里头 用模式 来定义 那些无 需纳入 Git 管理 
的 文件， 这样它 们不会 出现在 未跟踪 列表， 也 不会在 你运行 git add 后被 暂存。 然而， 如果你 
想 用项目 库之外 的文件 来定义 那些需 被忽略 的文件 的活， 用 core.excludesfile 通知 Git 该文件 
所处的 位置， 文件内 容和. gitignore 类似。 

help.autocorrect 

该配置 项只在 Git 1.6.1 及以 上版本 有效， 假 如你在 Git 1.6 中错打 了一条 命令， 会 显示： 
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$ git com 

git: 'com' is not a git-command. See 'git ― help'. 



Did you mean this? 
commit 



如 果你把 help.autocorrect 设置成 1 (译注 ： 启动自 动修正 ）， 那么 在只有 一个 命令被 模糊匹 
配 到的情 况下， Git 会自动 运行该 命令。 

7.1.2 Git 中 的着色 

Git 能够为 输出到 你终端 的内容 着色， 以 便你可 以凭直 观进行 快速、 简单地 分析， 有许多 
选项能 供你使 用以符 合你的 偏好。 

color.ui 

Git 会按 照你需 要自动 为大部 分的输 出加上 颜色， 你能 明确地 规定哪 些需要 着色以 及怎样 
着色， 设置 color.ui 为 true 来 打开所 有的默 认终端 着色。 



$ git config ― global color.ui true 



设置好 以后， 当输 出到终 端时， Git 会为 之加上 颜色。 其 他的参 数还有 false 和 always, 
false 意 味着不 为输出 着色， 而 always 则表 明在任 何情况 下都要 着色， 即使 Git 命令 被重定 
向到 文件或 管道。 Git 1.5.5 版 本引进 了此项 配置， 如果 你拥有 的版本 更老， 你 必须对 颜色有 
关 选项各 自进行 详细地 设置。 

你会很 少用到 color.ui = always, 在大 多数情 况下， 如果 你想在 被重定 向的输 出中插 入颜色 
码， 你 能传递 一color 标志给 Git 命 令来迫 使它这 么做， color.ui = tme 应该 是你的 首选。 

color.* 

想要具 体到哪 些命令 输出需 要被着 色以及 怎样着 色或者 Git 的版本 很老， 你 就要用 到和具 
体 命令有 关的颜 色配置 选项， 它 们都能 被置为 tme、 false 或 always: 



color.branch 
color.diff 
color-interactive 
color.status 

除此 之外， 以上每 个选项 都有子 选项， 可以被 用来覆 盖其父 设置， 以 达到为 输出的 各个部 
分 着色的 目的。 例如， 让 diff 输出 的改变 信息以 粗体、 蓝色前 景和黑 色背景 的形式 显示： 
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$ git config ― global color.diff.meta "blue black bold 



你能 设置 的颜色 值如： normak black, red、 green, yellow^ blue, magenta, cyan、 
white, 正如 以上例 子设置 的粗体 属性， 想要 设置字 体属性 的活， 可以选 择如： bold、 
dim、 ul、 blink, reverse。 

如果你 想配置 子选项 的活， 可 以参考 git config 帮 助页。 

7.1.3 外 部的合 并与比 较工具 

虽然 Git 自己 实现了 diff, 而且到 目前为 止你一 直在使 用它， 但 你能够 用一个 外部的 工具替 
代它， 除此 以外， 你 还能用 一个图 形化的 工具来 合并和 解决冲 突从而 不必自 己手动 解决。 有 
—个不 错且免 费的工 具可以 被用来 做比较 和合并 工作， 它就是 P4Merg e (译注 ： Perforce 
图 形化合 并工具 ） ， 我会 展示它 的安装 过程。 

P4M er ge 可 以在所 有主流 平台上 运行， 现 在开始 大胆尝 试吧。 对 于向你 展示的 例子， 在 
Mac 和 Linux 系 统上， 我会 使用路 径名， 在 Windows 上， /usr/local/bin 应该被 改为你 环境中 
的 可执行 路径。 

下载 P4Merge: 

http://www.perforce.com/ perf orce/d own loads/com ponent.html 

首先 把你要 运行的 命令放 入外部 包装脚 本中， 我 会使用 Mac 系 统上的 路径来 指定该 脚本的 
位置， 在 其他系 统上， 它应该 被放置 在二进 制文件 P 4m erge 所 在的目 录中。 创 建一个 merge 
包装 脚本， 名 字叫作 extMerge, 让 它带参 数调用 P 4m er ge 二进制 文件： 

$ cat /usr/local/bin/extMerge 
#!/bin/sh 

/Applications/p4merge.app/Contents/MacOS/p4merge $* 

diff 包装脚 本首先 确定传 递过来 7 个 参数， 随后 把其中 2 个 传递给 merge 包装 脚本， 默认情 
况下， Git 传 递以下 参数给 diff: 



path old-file old-hex old-mode new-file new-hex new-mode 



由 于你仅 仅需要 old- file 和 new- file 参数， 用 diff 包装 脚本来 传递它 们吧。 

$ cat /usr/local/bin/extDiff 
#!/bin/sh 

[ $# - eq 7 ] && /usr/local/bin/extMerge "$2" "$5" 
确 认这两 个脚本 是可执 行的： 
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$ sudo chmod + 


x /usr/local/bii 


n/extMerge 


$ sudo chmod + 


x /usr/local/bii 


n/extDiff 



现在来 配置使 用你自 定义的 比较和 合并工 具吧。 这需 要许多 自定义 设置： merge.tool 通知 
Git 使用哪 个合并 工具； mergetool.*.cmd 规 定命令 运行的 方式； mergetool.trustExitCode 会通知 
Git 程 序的退 出是否 指示合 并操作 成功； diff.extemal 通知 Git 用什么 命令做 比较。 因此， 你 
能运 行以下 4 条配置 命令： 



$ git config ― global merge. tool extMerge 

$ git config ― global mergetool.extMerge.cmd \ 

'extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"' 
$ git config —― global mergetool.trustExitCode false 
$ git config 一一 global diff.external extDiff 

或 者直接 编辑〜 /.gitcQnfig 文件 如下： 

[merge] 

tool = extMerge 
[mergetool "extMerge"] 

cmd = extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED" 

trustExitCode = false 
[diff] 

external = extDiff 




设置完 毕后， 运行 diff 命令: 



$ git diff 32d1776b1 A 32d1776b1 



命令行 居然没 有发现 diff 命令的 输出， 其实， Git 调用 了刚刚 设置的 P4Merg e , 它 看起来 
像图 7-1 这样： 

当你 设法合 并两个 分支， 结果 却有冲 突时， 运行 git mergetool, Git 会调用 P4Merge 让你 
通过图 形界面 来解决 冲突。 

设置 包装脚 本的好 处是你 能简单 地改变 diff 和 merge 工具， 例如把 extDiff 和 extMerge 改成 
KDiff3, 要做 的仅仅 是编辑 extMerge 脚本 文件： 

$ cat /usr/local/bin/extMerge 
#!/bin/sh 

/Applications/kdiff3.app/Contents/MacOS/kdiff3 $* 
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图 7.1: P 編 erge. 
现在 Git 会使用 KDiff3 来做 比较、 合并 和解决 冲突。 

Git 预先设 置了许 多其他 的合并 和解决 冲突的 工具， 而你不 必设置 cmd。 可 以把合 并工具 
设 置为： kdiff3、 opendi 幵、 tl〈diff、 meld, xxdiff、 emerge、 vimdiff、 gvimdiff。 女 口果你 
不 想用到 KDiff3 的所有 功能， 只是想 用它来 合并， 那么 kdiff3 正符 合你的 要求， 运行： 



$ git config ― global merge. tool kdiff3 



如 果运行 了以上 命令， 没 有设置 extMerge 和 extDiff 文件， Git 会用 KDiff3 做 合并， 让 通常内 
设的 比较工 具来做 比较。 

7.1.4 格式化 与空白 

格式化 与空白 是许多 开发人 员在协 作时， 特别 是在跨 平台情 况下， 遇 到的令 人头疼 的细小 
问题。 由 于编辑 器的不 同或者 Windows 程 序员在 跨平台 项目中 的文件 行尾加 入了回 车换行 
符， 一 些细微 的空格 变化会 不经意 地进入 大家合 作的工 作或提 交的补 丁中。 不 用怕， Git 的 
一些 配置选 项会帮 助你解 决这些 问题。 

core.autocrlf 

假如 你正在 Windows 上写 程序， 又 或者你 正在和 其他人 合作， 他们在 Windows 上 编程， 
而 你却在 其他系 统上， 在 这些情 况下， 你可 能会遇 到行尾 结束符 问题。 这 是因为 Windows 
使用 回车和 换行两 个字符 来结束 一行， 而 Mac 和 Linux 只 使用换 行一个 字符。 虽然这 是小问 
题， 但它 会极大 地扰乱 跨平台 协作。 

Git 可以在 你提交 时自动 地把行 结束符 CRLF 转换成 LF, 而在 签出代 码时把 LF 转换成 
CRLF。 用 core.autocrlf 来打 开此项 功能， 如 果是在 Windows 系 统上， 把它 设置成 tme, 这样 
当 签出代 码时， LF 会被 转换成 CRLF: 



$ git config ― global core.autocrlf true 
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Linux 或 Mac 系 统使用 LF 作 为行结 束符， 因此 你不想 Git 在签 出文件 时进行 自动的 转换； 
当 一个以 CRLF 为行结 束符的 文件不 小心被 引入时 你肯定 想进行 修正， 把 core.autocHf 设置成 
input 来告诉 Git 在提 交时把 CRLF 转换成 LF, 签 出时不 转换： 



$ git config ― global core.autocrlf input 



这 样会在 Windows 系统 上的签 出文件 中保留 CRLF, 会在 Mac 和 Linux 系 统上， 包 括仓库 
中保留 LF。 

如 果你是 Windows 程 序员， 且正在 开发仅 运行在 Windows 上的 项目， 可 以设置 false 取消 
此 功能， 把 回车符 记录在 库中： 



$ git config ― global core.autocrlf false 



core.whitespace 

Git 预先 设置了 一些选 项来探 测和修 正空白 问题， 其 4 种 主要选 项中的 2 个 默认被 打开， 另 2 
个被 关闭， 你可 以自由 地打开 或关闭 它们。 

默认被 打开的 2 个 选项是 trailing-space 和 space-before-tab, tmiling-space 会查 找每行 结尾的 
空格， space-before-tab 会 查找每 行开头 的制表 符前的 空格。 

默认被 关闭的 2 个 选项是 indent-with-non-tab 和 cr-at-eol, indent-with-non-tab 会查找 8 个以 
上空格 （ 非 制表符 ） 开头 的行， cr-at-eol 让 Git 知道行 尾回车 符是合 法的。 

设置 core.whitespace, 按照你 的意图 来打开 或关闭 选项， 选项 以逗号 分割。 通过逗 号分割 
的链中 去掉选 项或在 选项前 加-来 关闭， 例如， 如果你 想要打 开除了 cr-at-eol 之外的 所有选 
项： 



$ git config ― global core.whitespace \ 

trailing-space,space-before-tab, indent-with-non-tab 



当 你运行 git diff 命 令且为 输出着 色时， Git 探测 到这些 问题， 因此你 也许在 提交前 能修复 
它们， 当你用 git apply 打 补丁时 同样也 会从中 受益。 如果 正准备 运用的 补丁有 特别的 空白问 
题， 你 可以让 Git 发 警告： 



$ git apply -- whitespace=warn <patch> 



或者让 Git 在打 上补丁 前自动 修正此 问题: 



$ git apply ― whitespace=fix <patch> 

这些选 项也能 运用于 衍合。 如 果提交 了有空 白问题 的文件 但还没 推送到 上流， 你可 以运行 

带有 --whites P ace=fix 选项的 rebase 来让 Git 在 重写补 丁时自 动修正 它们。 
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7.1.5 服务器 端配置 

Git 服 务器端 的配置 选项并 不多， 但仍有 一些饶 有生趣 的选项 值得你 一看。 

receive.fsckObjects 

Git 默认 情况下 不会在 推送期 间检查 所有对 象的一 致性。 虽然 会确认 每个对 象的有 效性以 
及 是否仍 然匹配 SHA-1 检 验和， 但 Git 不会在 每次推 送时都 检查一 致性。 对于 Git 来说， 
库 或推送 的文件 越大， 这个操 作代价 就相对 越高， 每次推 送会消 耗更多 时间， 如果想 在每次 
推送时 Git 都 检查一 致性， 设置 receive.fsckObjects 为 true 来强 迫它这 么做： 



$ git config ― system receive.fsckObjects true 



现在 Git 会在 每次推 送生效 前检查 库的完 整性， 确保有 问题的 客户端 没有引 入破坏 性的数 

据。 

receive.denyNonFastForwards 

如果 对已经 被推送 的提交 历史做 衍合， 继而再 推送， 又 或者以 其它方 式推送 一个提 交历史 
至远程 分支， 且 该提交 历史没 在这个 远程分 支中， 这 样的推 送会被 拒绝。 这通 常是个 很好的 

禁止 策略， 但 有时你 在做衍 合并确 定要更 新远程 分支， 可以在 push 命 令后加 -f 标志来 强制更 

新。 

要 禁用这 样的强 制更新 功能， 可 以设置 receive.denyNonFastForwards: 



$ git config ― system receive.denyNonFastForwards true 



稍 后你会 看到， 用服 务器端 的接收 钩子也 能达到 同样的 目的。 这个方 法可以 做更细 致的控 
制， 例如： 禁 用特定 的用户 做强制 更新。 

receive.deny Deletes 

规避 denyNonFastForwards 策 略的方 法之一 就是用 户删除 分支， 然后推 回新的 引用。 在更新 
的 Git 版本中 （从 1.6.1 版本 开始） ， 把 receive.denyDeletes 设置为 true: 



$ git config ― system receive.denyDeletes true 



这样 会在推 送过程 中阻止 删除分 支和标 签一没 有用户 能够这 么做。 要删 除远程 分支， 必 
须从 服务器 手动删 除引用 文件。 通 过用户 访问控 制列表 也能这 么做， 在 本章结 尾将会 介绍这 
些 有趣的 方式。 

7.2 Git 属性 

一些设 置项也 能被运 用于特 定的路 径中， 这样， Git 以 对一个 特定的 子目录 或子文 件集运 
用 那些设 置项。 这些 设置项 被称为 Git 属性， 可以 在你目 录中的 .gitattributes 文件内 进行设 
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置 （通常 是你项 目的根 目录） ， 也 可以当 你不想 让这些 属性文 件和项 目文件 一同提 交时， 

在 .git/info/attributes 进行 设置。 

使用 属性， 你可以 对个别 文件或 目录定 义不同 的合并 策略， 让 Git 知 道怎样 比较非 文本文 
件， 在你提 交或签 出前让 Git 过滤 内容。 你将在 这部分 了解到 能在自 己的项 目中使 用的属 
性， 以 及一些 实例。 

7.2.1 二进 制文件 

你 可以用 Git 属性 让其知 道哪些 是二进 制文件 （ 以防 Git 没有识 别出来 ） ， 以及指 示怎样 
处 理这些 文件， 这点 很酷。 例如， 一些 文本文 件是由 机器产 生的， 而 且无法 比较， 而 一些二 
进制 文件可 以比较 一 你将会 了解到 怎样让 Git 识 别这些 文件。 

识 别二进 制文件 

一些 文件看 起来像 是文本 文件， 但其实 是作为 二进制 数据被 对待。 例如， 在 Mac 上的 
Xcode 项 目含有 一个以 .pbxproj 结尾的 文件， 它是由 记录设 置项的 IDE 写到 磁盘的 jSON 数据 
集 （纯 文本 javascript 数据类 型）。 虽然技 术上看 它是由 ASCII 字 符组成 的文本 文件， 但你 
并 不认为 如此， 因为 它确实 是一个 轻量级 数据库 一 如果有 2 人改变 了它， 你 通常无 法合并 
和比较 内容， 只有 机器才 能进行 识别和 操作， 于是， 你想把 它当成 二进制 文件。 

让 Git 把所有 pbxproj 文 件当成 二进制 文件， 在 .gitattributes 文件 中设置 如下： 




现在， Git 会尝 试转换 和修正 CRLF (回车 换行） 问题， 也不 会当你 在项目 中运行 git show 
或 gitdiff 时， 比较 不同的 内容。 在 Git 1.6 及之 后的版 本中， 可以用 一个宏 代替 -cHf -diff: 



.pbxproj binary 



比 较二进 制文件 

在 Git 1.6 及 以上版 本中， 你 能利用 Git 属性 来有效 地比较 二进制 文件。 可 以设置 Git 把二 
进制数 据转换 成文本 格式， 用 通常的 diff 来 比较。 

这 个特性 很酷， 而 且鲜为 人知， 因此我 会结合 实例来 讲解。 首先， 要 解决的 是最令 人头疼 
的 问题： 对 Word 文档进 行版本 控制。 很 多人对 Word 文 档又恨 又爱， 如果想 对其进 行版本 
控制， 你可以 把文件 加入到 Git 库中， 每 次修改 后提交 即可。 但 这样做 没有一 点实际 意义， 
因 为运行 git diff 命 令后， 你只 能得到 如下的 结果： 



$ git diff 

diff ― git a/chapter1.doc b/chapter1.doc 
index 88839c4..4afcb7c 100644 

Binary files a7chapter1.doc and b7chapter1.doc differ 
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你不 能直接 比较两 个不同 版本的 Word 文件， 除非进 行手动 扫描， 不 是吗？ Git 属 性能很 
好地 解决此 问题， 把 下面的 行加到 .gitattributes 文件： 



.doc diff=word 



当 你要看 比较结 果时， 如果 文件扩 展名是 "doc" , Git 调用 "word" 过 滤器。 什么 
是 "word" 过滤 器呢？ 其 实就是 Git 使用 strings 程序， 把 Word 文档 转换成 可读的 文本文 
件， 之后 再进行 比较： 



$ git config diff.word.textconv strings 



现在 如果在 两个快 照之间 比较以 .doc 结尾的 文件， Git 对 这些文 件运用 "word" 过 滤器， 
在比 较前把 Word 文 件转换 成文本 文件。 

下 面展示 了一个 实例， 我 把此书 的第一 章纳入 Git 管理， 在一 个段落 中加入 了一些 文本后 
保存， 之 后运行 gitdiff 命令， 得 到结果 如下： 

$ git diff 

diff ― git a/chapter1.doc b/chapterl.doc 
index c1c8a0a..b93c9e4 100644 
— a/chapter1.doc 
+++ b/chapter1.doc 

@@ -8,7 +8,8 @@ re going to cover Version Control Systems ( VCS) and Git basics 
re going to cover how to get it and set it up for the first time if you don 
t already have it on your system. 

In Chapter Two we will go over basic Git usage 一 how to use Git for the 80% 
一 s going on, modify stuff and contribute changes. If the book spontaneously 
+s going on, modify stuff and contribute changes. If the book spontaneously 
+Let's see if this works. 



Git 成功且 简洁地 显示出 我增加 的文本 "Let' s see if this works" 。 虽 然有些 瑕疵， 在 
末 尾显示 了一些 随机的 内容， 但确实 可以比 较了。 如果 你能找 到或自 己写个 Word 到 纯文本 
的 转换器 的活， 效果 可能会 更好。 strings 可以在 大部分 Mac 和 Linux 系统上 运行， 所 以它是 
处 理二进 制格式 的第一 选择。 

你还能 用这个 方法比 较图像 文件。 当比 较时， 对 jPEG 文 件运用 一个过 滤器， 它能 提炼出 
EXIF 信息 一 大部 分图像 格式使 用的元 数据。 如果你 下载并 安装了 exiftool 程序， 可以 用它参 
照 元数据 把图像 转换成 文本。 比较 的不同 结果将 会用文 本向你 展示： 

$ echo '*.png diff=exif » .gitattributes 
$ git config diff.exif.textconv exiftool 
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如 果在项 目中替 换了一 个图像 文件， 运行 git diff 命令 的结果 如下: 



diff ― git a/image. png b/image.png 
index 88839c4..4afcb7c 100644 
— a/image. png 
+++ b/image.png 
@@ -1,12 +1,12 @@ 
ExifTool Version Number : 7.74 

-File Size : 70 kB 

-File Modification Date/Time : 2009:04:21 07:02:45-07:00 
+File Size : 94 kB 

+File Modification Date/Time : 2009:04:21 07:02:43-07:00 



File Type 
MIME Type 
-Image Width 
-Image Height 
+lmage Width 
+lmage Height 
Bit Depth 
Color Type 



PNG 

image/png 
1058 
889 
1056 
827 
: 8 

: RGB with Alpha 



你会 发现文 件的尺 寸大小 发生了 改变。 

7.2.2 关键 字扩展 

使用 SVN 或 CVS 的开发 人员经 常要求 关键字 扩展。 在 Git 中， 你无 法在一 个文件 被提交 
后修 改它， 因为 Git 会先对 该文件 计算校 验和。 然而， 你可以 在签出 时注入 文本， 在 提交前 
删 除它。 Git 属性 提供了 2 种 方式这 么做。 

首先， 你 能够把 blob 的 SHA-1 校 验和自 动注入 文件的 $ld$ 字段。 如果在 一个 或多个 文件上 
设 置了此 字段， 当下次 你签出 分支的 时候， Git 用 blob 的 SHA-1 值替 换那个 字段。 注意， 这 
不 是提交 对象的 SH A 校 验和， 而是 blob 本 身的校 验和： 



$ echo '*.txt ident' » .gitattributes 
$ echo '$\d$' > testtxt 



下次 签出文 件时， Git 入了 blob 的 SHA 值: 



$ rm text.txt 

$ git checkout ― text.txt 
$ cat test.txt 

$ld: 42812b7653c7b88933f8a9d6cad0ca16714b9bb3 $ 
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然而， 这样 的显示 结果没 有多大 的实际 意义。 这个 SHA 的值 相当地 随机， 无法区 分日期 
的 前后， 所以， 如 果你在 CVS 或 Subversion 中用过 关键字 替换， 一定 会包含 一个日 期值。 

因此， 你 能写自 己的过 滤器， 在提交 文件到 暂存区 或签出 文件时 替换关 键字。 有 2 种过 
滤器， "clean" 和 "smudge" 。 在 .gitattributes 文 件中， 你能 对特定 的路径 设置一 个过滤 
器， 然后设 置处理 文件的 脚本， 这些 脚本会 在文件 签出前 （ "smudge" , 见图 7-2 ) 和提 
交到暂 存区前 （ "clean" , 见图 7-3 ) 被 调用。 这些过 滤器能 够做各 种有趣 的事。 



Staging Area Working Directory 





*.txt Filter 




flleA.txt 


















smudge 
















fileB.txt 






clean 






fileB.txt' 











fjleC.rb 




ffleC.rb 





git checkout 



图 7.2: 签 出时， "smudge" 过 滤器被 触发。 



Staging Area 



fileA.txt 



fileB.txt 



•txt Filter 



clean 



Working Directory 

] 



fileA.txt' 



fileB.txt' 



] 



fileC.rb 




flleC.rb 





git add 

图 7.3: 提交 到暂存 区时， "dean" 过 滤器被 触发。 

这里举 一个 简单的 例子： 在暂 存前， 用 indent ( 縮进 ） 程序过 滤所有 C 源代 码。 在 .gitattributes 文 
件 中设置 "indent" 过滤 器过滤 *.c 文件： 



■c filter=indent 



然后， 通 过以下 配置， 让 Git 知道 "indent" 过滤器 在遇到 "smudge" 和 "clean" 时 
分 别该做 什么： 



$ git config 一一 global filter.indent.clean indent 
$ git config 一一 global filter.indent.smudge cat 
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于是， 当 你暂存 *.c 文 件时， indent 程 序会被 触发， 在把它 们签出 之前， cat 程 序会被 触发。 
但 cat 程 序在这 里没什 么实际 作用。 这样的 组合， 使 C 源代 码在暂 存前被 indem 程序 过滤， 非 
常 有效。 

另一 个例子 是类似 [^：5的$0 3 化$ 关键字 扩展。 为了 演示， 需要 一个小 脚本， 接受文 件名参 
数， 得到项 目的最 新提交 日期， 最后 把日期 写入该 文件。 下面用 Ruby 脚本来 实现： 

#! /usr/bin/env ruby 
data = STDIN.read 

last-date = 、git log ― pretty=format:"%ad" -V 

puts data.gsub('$Date$'， '$Date: ' + last— date.to— s + 



该 脚本从 git log 命令中 得到最 新提交 日期， 找到 文件中 的所有 $^化$字 符串， 最后 把该日 
期填充 到$0 3 化$ 字符串 中一此 脚本很 简单， 你可 以选择 你喜欢 的编程 语言来 实现。 把该脚 
本 命名为 expancLdate, 放到正 确的路 径中， 之后 需要在 Git 中设 置一个 过滤器 （dater) ， 
让 它在签 出文件 时调用 expancLdate, 在 暂存文 件时用 PeH 清 除之： 

$ git config filter.dater.smudge expand— date 

$ git config filter.dater.clean 'perl -pe "sAWSDatet'WXSJAWSAWSDateXWS/"' 



这个 PeH 小程序 会删除 $0 3 化$字 符串里 多余的 字符， 恢复 $Date$ 原貌。 到目前 为止， 你的 

过 滤器已 经设置 完毕， 可以 开始测 试了。 打 开一个 文件， 在文件 中输入 $03化$关 键字， 然后 

设置 Git 属性： 

$ echo '# $Date$' > date_test.txt 

$ echo 'date*.txt filter=dater / » .gitattributes 



如果 暂存该 文件， 之后再 签出， 你会发 现关键 字被替 换了: 



$ git add date_test.txt .gitattributes 






$ git commit -m "Testing date expansion in Git" 






$ rm date_test.txt 






$ git checkout date_test.txt 






$ cat date_test.txt 






# $Date: Tue Apr 21 07:26:52 2009 - 0700$ 













虽说这 项技术 对自定 义应用 来说很 有用， 但 还是要 小心， 因为 .gitattributes 文 件会随 着项目 
一起 提交， 而 过滤器 （ 例如： dater ) 不会， 所以， 过滤 器不会 在所有 地方都 生效。 当 你在设 
计这 些过滤 器时要 注意， 即使 它们无 法正常 工作， 也要让 整个项 目运作 下去。 

7.2.3 导 出仓库 

G it 属性 在导出 项目归 档时也 能发挥 作用。 
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export-ignore 

当产生 一个归 档时， 可 以设置 Git 不导 出某些 文件和 目录。 如 果你不 想在归 档中包 含一个 
子 目录或 文件， 但想他 们纳入 项目的 版本管 理中， 你 能对应 地设置 export-ignore 属性。 

例如， 在 test/ 子目录 中有一 些测试 文件， 在 项目的 压缩包 中包含 他们是 没有意 义的。 因 
此， 可以增 加下面 这行到 Git 属性文 件中： 



test/ export-ignore 




现在， 当运行 git archive 来创 建项目 的压縮 包时， 那 个目录 不会在 归档中 出现。 



export-subst 

还能 对归档 做一些 简单的 关键字 替换。 在第 2 章中已 经可以 看到， 可以以 - - preuy—ormat 形 
式的简 码在任 何文件 中放入 $F 0 rniat : $ 字 符串。 例如， 如 果想在 项目中 包含一 个叫作 LAST_COMMIT 的 
文件， 当运行 git archive 时， 最 后提交 日期自 动地注 入进该 文件， 可 以这样 设置： 

$ echo 'Last commit date: $Format:%cd$' > LAST-COMMIT 
$ echo M LAST_COMMIT export-subst" » .gitattributes 
$ git add LAST-COMMIT .gitattributes 
$ git commit -am 'adding LAST-COMMIT file for archives' 

运行 git archive 后， 打开该 文件， 会发现 其内容 如下： 



$ cat LAST-COMMIT 

Last commit date: $Format:Tue Apr 21 08:38:48 2009 -0700$ 




7.2.4 合 并策略 

通过 Git 属性， 还能对 项目中 的特定 文件使 用不同 的合并 策略。 一 个非常 有用的 选项就 
是， 当一些 特定文 件发生 冲突， Git 会尝 试合并 他们， 而 使用你 这边的 合并。 

如果项 目的一 个分支 有歧义 或比较 特别， 但 你想从 该分支 合并， 而且 需要忽 略其中 某些文 
件， 这样的 合并策 略是有 用的。 例如， 你有 一个数 据库设 置文件 database.xml, 在 2 个分支 
中他 们是不 同的， 你 想合并 一个分 支到另 一个， 而不 弄乱该 数据库 文件， 可 以设置 属性如 
下： 



database. xml merge=ours 




如果 合并到 另一个 分支， database.xml 文 件不会 有合并 冲突， 显示 如下: 
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$ git merge topic 
Auto-merging database. xm 
Merge made by recursive. 



这样， database.xml 会保持 原样。 



7.3 Git 挂钩 

和其他 版本控 制系统 一样， 当某 些重要 事件发 生时， Git 以调用 自定义 脚本。 有 两组挂 

钩： 客户端 和服务 器端。 客户 端挂钩 用于客 户端的 操作， 如 提交和 合并。 服务 器端挂 钩用于 

Git 服务 器端的 操作， 如 接收被 推送的 提交。 你 可以随 意地使 用这些 挂钩， 下 面会讲 解其中 
—些 o 

7.3.1 安装一 个挂钩 

挂 钩都被 存储在 Git 目 录下的 hooks 子目 录中， 即大部 分项目 中的. git/h 00 ks。 Git 默认会 
放置一 些脚本 样本在 这个目 录中， 除了 可以作 为挂钩 使用， 这 些样本 本身是 可以独 立使用 
的。 所 有的样 本都是 shell 脚本， 其中 一些还 包含了 Perl 的 脚本， 不过， 任何正 确命名 的可执 
行脚 本都可 以正常 使用一 可以用 Ruby 或 Python, 或 其他。 在 Git 1.6 版本 之后， 这 些样本 
名 都是以 .sample 结尾， 因此， 你必 须重新 命名。 在 Git 1.6 版本 之前， 这些样 本名都 是正确 
的， 但 这些样 本不是 可执行 文件。 

把 一个正 确命名 且可执 行的文 件放入 Git 目 录下的 hooks 子目 录中， 可以 激活该 挂钩脚 
本， 因此， 之 后他一 直会被 Git 调用。 随 后会讲 解主要 的挂钩 脚本。 

7.3.2 客户 端挂钩 

有许多 客户端 挂钩， 以下 把他们 分为： 提交 工作流 挂钩、 电子 邮件工 作流挂 钩及其 他客户 

端 挂钩。 

提 交工作 流挂钩 

有 4 个挂 钩被用 来处理 提交的 过程。 pre-commit 挂 钩在键 入提交 信息前 运行， 被用 来检查 
即将 提交的 快照， 例如， 检查 是否有 东西被 遗漏， 确认测 试是否 运行， 以 及检查 代码。 当从 
该 挂钩返 回非零 值时， Git 放 弃此次 提交， 但 可以用 git commit -no-verify 来 忽略。 该 挂钩可 
以 被用来 检查代 码错误 （运 行类似 lint 的 程序） ， 检查尾 部空白 （默 认挂钩 是这么 做的） ， 
检查 新方法 （译注 ： 程序的 函数） 的 说明。 

prepare-commit-msg 挂钩在 提交信 息编辑 器显示 之前， 默认信 息被创 建之后 运行。 因此， 
可 以有机 会在提 交作者 看到默 认信息 前进行 编辑。 该 挂钩接 收一些 选项： 拥有 提交信 息的文 
件 路径， 提交 类型， 如 果是一 次修订 的活， 提交的 SHA-1 校 验和。 该 挂钩对 通常的 提交来 
说 不是很 有用， 只在自 动产生 的默认 提交信 息的情 况下有 作用， 如提 交信息 模板、 合并、 压 
缩和 修订提 交等。 可以和 提交模 板配合 使用， 以编 程的方 式插入 信息。 

commit-msg 挂钩接 收一个 参数， 此参数 是包含 最近提 交信息 的临时 文件的 路径。 如果该 
挂 钩脚本 以非零 退出， Git 放弃 提交， 因此， 可以 用来在 提交通 过前验 证项目 状态或 提交信 
息。 本章 上一小 节已经 展示了 使用该 挂钩核 对提交 信息是 否符合 特定的 模式。 
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post-commit 挂钩在 整个提 交过程 完成后 运行， 他 不会接 收任何 参数， 但可 以运行 git log -1 
HEAD 来获 得最后 的提交 信息。 总之， 该挂 钩是作 为通知 之类使 用的。 

提 交工作 流的客 户端挂 钩脚本 可以在 任何工 作流中 使用， 他们 经常被 用来实 施某些 策略， 
但值 得注意 的是， 这些 脚本在 clone 期间 不会被 传送。 可 以在服 务器端 实施策 略来拒 绝不符 
合某些 策略的 推送， 但这完 全取决 于开发 者在客 户端使 用这些 脚本的 情况。 所以， 这 些脚本 
对开发 者是有 用的， 由他 们自己 设置和 维护， 而且 在任何 时候都 可以覆 盖或修 改这些 脚本。 

E-mail 工作 流挂钩 

有 3 个可 用的客 户端挂 钩用于 e-mail 工 作流。 当运行 git am 命 令时， 会调用 他们， 因此， 
如 果你没 有在工 作流中 用到此 命令， 可 以跳过 本节。 如果 你通过 e-mail 接收由 git format- 
patch 产生的 补丁， 这些 挂钩也 许对你 有用。 

首先运 行的是 applypatch-msg 挂钩， 他接收 一个 参数： 包含 被建议 提交信 息的临 时文件 
名。 如 果该脚 本非零 退出， Git 放弃此 补丁。 可以 使用这 个脚本 确认提 交信息 是否被 正确格 
式化， 或让脚 本编辑 信息以 达到标 准化。 

下 一个在 git am 运 行期间 调用是 pre -a PP l VpatC h 挂钩。 该挂钩 不接收 参数， 在 补丁被 运用之 
后 运行， 因此， 可以 被用来 在提交 前检查 快照。 你能 用此脚 本运行 测试， 检查工 作树。 如果 
有 些什么 遗漏， 或 测试没 通过， 脚本会 以非零 退出， 放 弃此次 git am 的 运行， 补丁不 会被提 
交。 

最后在 git am 运行 期间调 用的是 post-applypatch 挂钩。 你可以 用他来 通知一 个 小组或 获取的 
补丁的 作者， 但无法 阻止打 补丁的 过程。 

其 他客户 端挂钩 

pre-rebase 挂钩在 衍合前 运行， 脚本 以非零 退出可 以中止 衍合的 过程。 你可 以使用 这个挂 
钩 来禁止 衍合已 经推送 的提交 对象， Git pre-rebase 挂钩 样本就 是这么 做的。 该样 本假定 next 
是你定 义的分 支名， 因此， 你可能 要修改 样本， 把 next 改成 你定义 过且稳 定的分 支名。 

在 git checkout 成功运 行后， post-checkout 挂 钩会被 调用。 他可 以用来 为你的 项目环 境设置 
合适 的工作 目录。 例如： 放 入大的 二进制 文件、 自 动产生 的文档 或其他 一切你 不想纳 入版本 
控制的 文件。 

最后， 在 merge 命令 成功执 行后， post-merge 挂 钩会被 调用。 他可以 用来在 Git 无 法跟踪 
的 工作树 中恢复 数据， 诸 如权限 数据。 该 挂钩同 样能够 验证在 Git 控 制之外 的文件 是否存 
在， 因此， 当工 作树改 变时， 你想这 些文件 可以被 复制。 

7.3.3 服务器 端挂钩 

除了 客户端 挂钩， 作为 系统管 理员， 你还 可以使 用两个 服务器 端的挂 钩对项 目实施 各种类 
型的 策略。 这些挂 钩脚本 可以在 提交对 象推送 到服务 器前被 调用， 也可 以在推 送到服 务器后 
被 调用。 推 送到服 务器前 调用的 挂钩可 以在任 何时候 以非零 退出， 拒绝 推送， 返回错 误消息 
给客 户端， 还 可以如 你所愿 设置足 够复杂 的推送 策略。 

pre - receive 禾口 post- receive 

处 理来自 客户端 的推送 （ push ) 操作时 最先执 行的脚 本就是 pre-receive 。 它从标 准输入 
(stdin) 获取 被推送 引用的 列表； 如果它 退出时 的返回 值不是 0, 所 有推送 内容都 不会被 
接受。 利 用此挂 钩脚本 可以实 现类似 保证最 新的索 引中不 包含非 fast-forward 类型的 这类效 
果； 抑或检 查执行 推送操 作的用 户拥有 创建， 删除 或者推 送的权 限或者 他是否 对将要 修改的 
每一个 文件都 有访问 权限。 



191 



第 7 章 自定义 Git 



Scott Chacon Pro Git 



post-receive 挂钩 在整个 过程完 结以后 运行， 可 以用来 更新其 他系统 服务或 者通知 用户。 
它 接受与 pre-receive 相 同的标 准输入 数据。 应用实 例包括 给某邮 件列表 发信， 通知 实时整 
合数 据的服 务器， 或者更 新软件 项目的 问题追 踪系统 —— 甚至 可以通 过分析 提交信 息来决 
定 某个问 题是否 应该被 开启， 修 改或者 关闭。 该脚本 无法组 织推送 进程， 不过 客户端 在它完 
成 运行之 前将保 持连接 状态； 所以在 用它作 一些消 耗时间 的操作 之前请 三思。 

update 

update 脚本和 pre- receive 脚 本十分 类似。 不同 之处在 于它会 为推送 者更新 的每一 个分 
支运行 一次。 假如 推送者 同时向 多个分 支推送 内容， pre-receive 只运行 一次， 相 比之下 
update 则 会为每 一个更 新的分 支运行 一次。 它 不会从 标准输 入读取 内容， 而 是接受 三个参 
数： 索引 的名字 （分支 ）， 推送 前索引 指向的 内容的 SHA-1 值， 以及 用户试 图推送 内容的 
SHA-1 值。 如果 update 脚本以 退出时 返回非 零值， 只有相 应的那 一个索 引会被 拒绝； 其 
余 的依然 会得到 更新。 

7.4 Git 强制策 略实例 

在本 节中， 我们 应用前 面学到 的知识 建立这 样一个 Git 工作 流程： 检 查提交 信息的 格式， 
只 接受纯 fast-forward 内容的 推送， 并且 指定用 户只能 修改项 目中的 特定子 目录。 我 们将写 
一 个客户 端角本 来提示 开发人 员他们 推送的 内容是 否会被 拒绝， 以及一 个服务 端脚本 来实际 
执 行这些 策略。 

这些脚 本使用 Ruby 写成， 一 半由于 它是作 者倾向 的脚本 语言， 另外 作者觉 得它是 最接近 
伪代码 的脚本 语言； 因而 即便你 不使用 Ruby 也 能大致 看懂。 不过任 何其他 语言也 一样适 
用。 所有 Git 自 带的样 例脚本 都是用 Perl 或 Bash 写的。 所以 从这些 脚本中 能找到 相当多 
的这两 种语言 的挂钩 样例。 

7.4.1 服务 端挂钩 

所 有服务 端的工 作都在 hooks (挂钩 ） 目录的 update (更新 ） 脚本中 制定。 update 脚本 
为 每一个 得到推 送的分 支运行 一次； 它接 受推送 目标的 索引， 该分 支原来 指向的 位置， 以及 
被推 送的新 内容。 如 果推送 是通过 SSH 进 行的， 还可以 获取发 出此次 操作的 用户。 如果设 
定所 有操作 都通过 公匙授 权的单 一帐号 （ 比如 " git " ) 进行， 就有 必要通 过一个 shell 包装 
依 据公匙 来判断 用户的 身份， 并且设 定环境 变量来 表示该 用户的 身份。 下面假 设尝试 连接的 
用户 储存在 $USER 环境变 量里， 我们的 update 脚本 首先搜 集一切 需要的 信息： 



#!/usr/bin/env ruby 

$refname = ARGV[0] 
$oldrev = ARGV[1] 
$newrev = ARGV[2] 
$user = ENVPUSER'] 



puts "Enforcing Policies... \n (#{$refname} ) (#{$oldrev[0，6]} ) (#{$newrev[0，6]} ) 




没错， 我在 用全局 变量。 别 鄙视我 —— 这样 比较利 于演示 过程。 
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指定 特殊的 提交信 息格式 

我 们的第 一项任 务是指 定每一 条提交 信息都 必须遵 循某种 特殊的 格式。 作为 演示， 假定每 
—条信 息必须 包含一 条形似 "ref: 1234" 这 样的字 符串， 因为我 们需要 把每一 次提 交和项 
目的问 题追踪 系统。 我们 要逐一 检查每 一条推 送上来 的提交 内容， 看看 提交信 息是否 包含这 
么 一个字 符串， 然后， 如果该 提交里 不包含 这个字 符串， 以非零 返回值 退出从 而拒绝 此次推 

送。 

把 $newrev 和 $oldrev 变 量的值 传给一 个叫做 git rev-list 的 Git plumbing 命令可 以获取 
所 有提交 内容的 SHA-1 值 列表。 git rev-list 基 本类似 git log 命令， 但 它默认 只输出 SHA-1 
值 而已， 没 有其他 信息。 所以要 获取由 SHA 值表 示的从 一次提 交到另 一次提 交之间 的所有 
SHA 值， 可以 运行： 



$ git rev-list 538c33..d14fc7 

d14fc7c847ab946ec39590d87783c69b031bdfb7 

9f585da4401b0a3999e84113824d15245c13f0be 

234071a1be950e2a8d078e6141f5cd20c1e61ad3 

dfa04c9ef3d5197182f13fb5b9b1fb7717d2222a 

1771 6ec0f 1 ff 5c77eff 40b7f e91 2f 9f 6cf d0e475 



截取这 些输出 内容， 循环遍 历其中 每一个 SHA 值， 找出与 之对应 的提交 信息， 然 后用正 
则表 达式来 测试该 信息包 含的格 式活的 内容。 

下面要 搞定如 何从所 有的提 交内容 中提取 出提交 信息。 使 用另一 个叫做 git cat-file 的 Git 
Plumbing 工具 可以获 得原始 的提交 数据。 我们将 在第九 章了解 到这些 plumbing 工 具的细 
节； 现 在暂时 先看一 下这条 命令的 输出： 



$ git cat-file commit ca82a6 

tree Cfda3bf379e4f8dba8717dee55aab78aef7f4daf 

parent 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 

author Scott Chacon <schacon@gmail.com> 1205815931 - 0700 

committer Scott Chacon <schacon@gmail.com> 1240030591 一 0700 



changed the version number 



通过 SHA-1 值获得 提交内 容中的 提交信 息的一 个简单 办法是 找到提 交的第 一行， 然后取 
从 它往后 的所有 内容。 可 以使用 Unix 系统的 sed 命令来 实现该 效果： 



$ git cat-file commit ca82a6 I sed '1,/ A $/d' 
changed the version number 

这条咒 语从每 一个待 提交内 容里提 取提交 信息， 并且会 在提取 信息不 符合要 求的情 况下退 
出。 为了 退出脚 本和拒 绝此次 推送， 返回 一个非 零值。 整个脚 本大致 如下： 
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$regex = /\[ref: (\d+)W 




# 指定 提交信 息格式 




def check- message -format 




missed — revs = 'git rev-list #{$oldre 


v}..#{$newrev}\split("\n") 


missed — revs.each do I rev I 




message = 、git cat-file commit #{i 


rev} I sed '1，/ A $/d'、 


if !$regex.match ( message) 




puts "[POLICY] Your message is 


not formatted correctly" 


exit 1 




end 




end 




end 




check- message -format 





把这一 段放在 update 脚 本里， 所有包 含不符 合指定 规则的 提交都 会遭到 拒绝。 

实现基 于用户 的访问 权限控 制列表 （ ACL ) 系统 

假设你 需要添 加一个 使用访 问权限 控制列 表的机 制来指 定哪些 用户对 项目的 哪些部 分有推 
送 权限。 某 些用户 具有全 部的访 问权， 其 他人只 对某些 子目录 或者特 定的文 件具有 推送权 
限。 要 搞定这 一点， 所 有的规 则将被 写入一 个位于 服务器 的原始 Git 仓库的 ad 文件。 我们 
让 update 挂钩检 阅这些 规则， 审视 推送的 提交内 容中需 要修改 的所有 文件， 然后决 定执行 
推 送的用 户是否 对所有 这些文 件都有 权限。 

我们首 先要创 建这个 列表。 这里 使用的 格式和 CVS 的 ACL 机 制十分 类似： 它由 若干行 
构成， 第一项 内容是 avail 或者 unavail, 接着 是逗号 分隔的 规则生 效用户 列表， 最后 一项是 
规 则生效 的目录 （空 白表 示开放 访问） 。 这些 项目由 I 字符 隔开。 

下 例中， 我 们指定 几个管 理员， 几个对 doc 目录具 有权限 的文档 作者， 以及 一个对 lib 和 
tests 目录具 有权限 的开发 人员， 相应的 ACL 文件 如下： 

avail I nickh,pjhyett,defunkt,tpw 
avail I usinclair,cdickens,ebronte Idoc 
avail I schacon I lib 
availlschaconltests 



首先把 这些数 据读入 你编写 的数据 结构。 本 例中， 为保持 简洁， 我 们暂时 只实现 avail 的 
规则 （ 译注： 也就是 省略了 unavail 部分 ） 。 下面这 个方法 生成一 个关联 数组， 它的 主键是 
用 户名， 值 是一个 该用户 有写权 限的所 有目录 组成的 数组： 

def get— acl— access— data (acl— file) 
# read in ACL data 



194 



Scott Chacon Pro Git 



7.4 节 Git 强制策 略实例 



acLfile = File. read (acLfile). split ("\n"). reject { I lir 


ie 1 line == " } 


access = {} 




acLfile.each do I line I 




avail, users, path = line.split(' I') 




next unless avail == 'avail' 




users. split('/). each do 1 user I 




accesstuser] N= [] 




accesstuser] « path 




end 




end 




access 




end 





针 对之前 给出的 ACL 规则 文件， 这个 g e t_ ac L aCCeSS _dat a 方法返 回的数 据结构 如下: 



{"defunkt"=>[nil], 




"tpw"=>[nii], 




"nickh"=>[nil], 




"pjhyett"=>[nil], 




M schacon"=>[ M lib M , "tests"], 




"cdickens'^P'doc"], 




"usinclair'^fdoc"], 




M ebronte"=>["doc"]} 





搞定 了用户 权限的 数据， 下面需 要找出 哪些位 置将要 被提交 的内容 修改， 从 而确保 试图推 
送 的用户 对这些 位置有 全部的 权限。 

使用 git log 的 -- name-only 选项 （ 在 第二章 里简单 的提过 ） 我们 可以轻 而易举 的找出 一次 
提交里 修改的 文件： 



$ git log -1 -- name-only -- pretty=format:" 9f585d 

README 
lib/test.rb 



使用 geLacLaccess-data 返回的 ACL 结构来 一一 核对每 一次提 交修改 的文件 列表， 就能 
找出 该用户 是否有 权限推 送所有 的提交 内容： 

# 仅 允许特 定用户 修改项 目 中 的 特定子 目 录 

def check-directory-perms 
access = get— acl— access— data('acl') 
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# 检查 是否有 人在向 他没有 权限的 地方推 送内容 
new— commits = 、git rev-list #{$oldrev}..#{$newrev}、.split("\n") 
new_comm its. each do I rev I 
files— modified = 、git log -1 一一 name-only 一一 pretty=format:" #{rev}、.split("\n") 
files-inodified.each do I path I 
next if path. size == 0 
has-file— access = false 
access[$user].each do I access— path I 
if ！ access-path I I # 用 户拥有 完全访 问权限 
(path.index(access-path) == 0) # 或者对 此位置 有访问 权限 
has_file— access = true 
end 
end 

if ！ has— file— access 
puts "[POLICY] You do not have access to push to #{path}" 
exit 1 
end 
end 
end 
end 

check-directory-perms 



以上的 大部分 内容应 该都比 较容易 理解。 通过 git rev-list 获取 推送到 服务器 内容的 提交列 
表。 然后， 针对 其中每 一项， 找出它 试图修 改的文 件然后 确保执 行推送 的用户 对这些 文件具 
有 权限。 一个不 太容易 理解的 Ruby 技巧石 pa th.i n d ex ( access _path) ==0 这句， 它的返 回真值 
如果 路径以 access-path 开头 —— 这是为 了确保 a CCeSS _ P ath 并 不是只 在允许 的路径 之一， 而 
是所 有准许 全选的 目 录 都在该 目 录 之下。 

现在你 的用户 没法推 送带有 不正确 的提交 信息的 内容， 也不能 在准许 他们访 问范围 之外的 
位 置做出 修改。 

只允许 Fast-Forward 类型 的推送 

剩下的 最后一 项任务 是指定 只接受 fast-forward 的 推送。 在 Git 1.6 或者 更新版 本里， 
只需 要设定 receive.denyDeletes 禾口 receive.denyNonFastForwards 选 项就可 以了。 但是 通过挂 
钩的 实现可 以在旧 版本的 Git 上 工作， 并且 通过一 定的修 改它它 可以做 到只针 对某些 用户执 
行， 或者更 多以后 可能用 的到的 规则。 

检查 这一项 的逻辑 是看看 提交里 是否包 含从旧 版本里 能找到 但在新 版本里 却找不 到的内 
容。 如果 没有， 那这是 一次纯 fast-forward 的 推送； 如 果有， 那 我们拒 绝此次 推送： 

# 只 允许纯 fast-forward 推送 
def check_fast_forward 
missed — refs = 、git rev-list #{$newrev}..#{$oldrev}、 
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missed — ref— count = missed-refs.split("\n").size 
if missed — ref— count > 0 

puts "[POLICY] Cannot push a non fast-forward reference" 

exit 1 
end 
end 

check-fast_forward 

—切 都设定 好了。 如果现 在运行 chmod u + x .git/hooks/update —— 修 改包含 以上内 容文件 
的 权限， 然后 尝试推 送一个 包含非 fast-forward 类型的 索引， 会得 到一下 提示： 

$ git push - f origin master 
Counting objects: 5, done. 
Compressing objects: 100% (3/3)， done. 
Writing objects: 100% (3/3), 323 bytes, done. 
Total 3 (delta 1), reused 0 (delta 0) 
Unpacking objects: 100% (3/3)， done. 
Enforcing Policies... 

(refs/heads/master) (8338c5) (c5b616) 
[POLICY] Cannot push a non-fast-forward reference 
error: hooks/update exited with error code 1 
error: hook declined to update refs/heads/master 
To git@gitserver:project.git 

！ [remote rejected] master -> master ( hook declined ) 
error: failed to push some refs to 'gitOgitserveriproject.gif 

这里 有几个 有趣的 信息。 首先， 我们 可以看 到挂钩 运行的 起点： 

Enforcing Policies... 

(refs/heads/master) (fb8c72) (c56860) 



注意 这是从 update 脚本 开头输 出到标 准你输 出的。 所 有从脚 本输出 的提示 都会发 送到客 
户端， 这点很 重要。 
下一个 值得注 意的部 分是错 误信息 。 

[POLICY] Cannot push a non fast-forward reference 
error: hooks/update exited with error code 1 
error: hook declined to update refs/heads/master 
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第一 行是 我们的 脚本输 出的， 在 往下是 Git 在告 诉我们 update 脚本 退出时 返回了 非零值 
因 而推送 遭到了 拒绝。 最后 一点： 



To git@gitserver:project.git 

！ [remote rejected] master -> master (hook declined) 
error: failed to push some refs to 'git@gitserver:project.git' 



我们 将为每 一个被 挂钩拒 之门外 的索引 受到一 条远程 信息， 解 释它被 拒绝是 因为一 个挂钩 
的 原因。 

而且， 如 果那个 ref 字符串 没有包 含在任 何的提 交里， 我们将 看到前 面脚本 里输出 的错误 

1h 息 ： 



[POLICY] Your message is not formatted correctly 

又 或者某 人想修 改一个 自己不 具备权 限的文 件然后 推送了 一个包 含它的 提交， 他将 看到类 
似的 提示。 比如， 一个文 档作者 尝试推 送一个 修改到 nb 目录的 提交， 他 会看到 



[POLICY] You do not have access to push to lib/test. rb 



全在 这了。 从这里 开始， 只要 update 脚 本存在 并且可 执行， 我们的 仓库永 远都不 会遭到 
回 转或者 包含不 符合要 求信息 的提交 内容， 并且 用户都 被锁在 了沙箱 里面。 

7.4.2 客户 端挂钩 

这种手 段的缺 点在于 用户推 送内容 遭到拒 绝后几 乎无法 避免的 抱怨。 辛辛苦 苦写成 的代码 
在最后 时刻惨 遭拒绝 是十分 悲剧切 具迷惑 性的； 更 可怜的 是他们 不得不 修改提 交历史 来解决 
问题， 这 怎么也 算不上 王道。 

逃离这 种两难 境地的 法宝是 给用户 一些客 户端的 挂钩， 在他们 作出可 能悲剧 的事情 的时候 
给以 警告。 然 后呢， 用户们 就能在 提交口 问题变 得更难 修正之 前解除 隐患。 由 于挂钩 本身不 

跟随克 隆的项 目副本 分发， 所以必 须通过 其他途 径把这 些挂钩 分发到 用户的 .git/hooks 目 
录 并设为 可执行 文件。 虽然可 以在相 同或单 独的项 目内容 里加入 并分发 它们， 全自 动的解 
决方案 是不存 在的。 

首先， 你应 该在每 次提交 前核查 你的提 交注释 信息， 这 样你才 能确保 服务器 不会因 为不合 
条件 的提交 注释信 息而拒 绝你的 更改。 为了达 到这个 目的， 你可以 增加' commit-msg' 挂 
钩。 如果你 使用该 挂钩来 阅读作 为第一 个参数 传递给 git 的提 交注释 信息， 并 且与规 定的模 
式作 对比， 你就 可以使 git 在提 交注释 信息不 符合条 件的情 况下， 拒 绝执行 提交。 



#!/usr/bin/env ruby 

message-file = ARGV[0] 

message = File.reacK message-file) 
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$regex = A[ref: (\d+)\]/ 

if !$regex. match (message) 

puts "[POLICY] Your message is not formatted correctly 1 

exit 1 
end 




如果这 个脚本 放在这 个位置 （.git/hooks/commit-msg) 并且 是可执 行的， 并且 你的提 交注释 
信 息不是 符合要 求的， 你会 看到： 

$ git commit -am 'test' 

[POLICY] Your message is not formatted correctly 



在 这个实 例中， 提 交没有 成功。 然 而如果 你的提 交注释 信息是 符合要 求的， git 会 允许你 
提交： 



$ git commit -am 'test [ref: 132]' 
[master e05c914] test [ref: 132] 
1 files changed, 1 insertions( + ), 0 deletions ( — ) 



接 下来我 们要保 证没有 修改到 ACL 允 许范围 之外的 文件。 加 入你的 .git 目 录里有 前面使 
用过的 ACL 文件， 那么 以下的 pre-commit 脚本 将把里 面的规 定执行 起来： 

#!/usr/bin/env ruby 
$user = ENVPUSER'] 

# [ insert acl— access— data method from above ] 

# 只允 许特定 用户修 改项目 重特定 子目录 的内容 
def check-directory-perms 
access = get— acl— access— data('.git/acl') 

files — modified = 、git di 幵- index -- cached -- name-only HEAD\split("\n") 
files-inodified.each do I path I 

next if path. size == 0 

has-file— access = false 

access[$user].each do I access— path I 

if ！ access-path 1 1 (path.index(access-path) == 0) 
has— file— access = true 
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end 

if ！ has— file— access 
puts "[POLICY] You do not have access to push to #{path}" 
exit 1 
end 
end 
end 

check-directory-perms 

这 和服务 端的脚 本几乎 一样， 除了两 个重要 区别。 第一， ACL 文件 的位置 不同， 因为这 
个 脚本在 当前工 作目录 运行， 而非 Git 目录。 ACL 文件 的目录 必须从 



access = get— acl — access— data('acl') 



修 改成: 



access = get— acl — access— data('.git/acl') 



另一个 重要区 别是获 取被修 改文件 列表的 方式。 在服务 端的时 候使用 了查看 提交纪 录的方 
式， 可是 目前的 提交都 还没被 记录下 来呢， 所 以这个 列表只 能从暂 存区域 获取。 和 原来的 



files— modified = 、git log -1 -- name-only -- pretty=format: // #{ref} 



不同， 现 在要用 



files— modified = 、git diff— index ― cached ― name-only HEAD' 



不同的 就只有 这两点 —— 除此 之外， 该脚 本完全 相同。 一个小 陷阱在 于它假 设在本 地运行 
的 账户和 推送到 远程服 务端的 相同。 如果这 二者不 一样， 则需要 手动设 置一下 $ user 变量。 

最后 一项任 务是检 查确认 推送内 容中不 包含非 fast-forward 类型的 索引， 不过这 个需求 
比较 少见。 要找出 一个非 fast-forward 类型的 索引， 要么衍 合超过 某个已 经推送 过的提 
交， 要么从 本地不 同分支 推送到 远程相 同的分 支上。 

既 然服务 器将给 出无法 推送非 fast-forward 内容的 提示， 而 且上面 的挂钩 也能阻 止强制 
的 推送， 唯一 剩下的 潜在问 题就是 衍合一 次已经 推送过 的提交 内容。 

下面是 一个检 查这个 问题的 pre-rabase 脚本的 例子。 它获取 一个所 有即将 重写的 提交内 
容的 列表， 然后 检查它 们是否 在远程 的索引 里已经 存在。 一旦发 现某个 提交可 以从远 程索引 
里衍变 过来， 它就放 弃衍合 操作： 
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#!/usr/bin/env ruby 

base-branch = ARGV[0] 
if ARGV[1] 

topic-branch = ARGV[1] 
else 

topic— branch = "HEAD" 
end 

target— shas = 、git rev-list #{base— branch}..#{topic— branchL.splitO") 
remote—refs = 、git branch -r\split("\n").map { I r I r.strip } 

target— shas.each do Isha I 
remote — refs.each do I remote_ref I 
shas— pushed = 、git rev-list A #{sha} A @ refs/remotes/#{remote — ref}、 
if shas_pushed.split( "\n" ).include?(sha) 
puts "[POLICY] Commit #{sha} has already been pushed to #{remote— ref}" 
exit 1 
end 
end 
end 

这个脚 本利用 了一个 第六章 "修 订版本 选择" 一节 中不曾 提到的 语法。 通过 这一句 可以获 
得一个 所有已 经完成 推送的 提交的 列表： 

git rev-list A #{sha} A @ refs/remotes/#{remote— ref} 



SHAQ@ 语法 解析该 次提交 的所有 祖先。 这 里我们 从检查 远程最 后一次 提交能 够衍变 
获 得但从 所有我 们尝试 推送的 提交的 SHA 值祖 先无法 衍变获 得的提 交内容 —— 也就是 
fast-forward 的 内容。 

这 个解决 方案的 硬伤在 于它有 可能很 慢而且 常常没 有必要 —— 只 要不用 -f 来强制 推送， 
服 务器会 自动给 出警告 并且拒 绝推送 内容。 然而， 这是个 不错的 练习而 且理论 上能帮 助用户 
避免 一次将 来不得 不折回 来修改 的衍合 操作。 

7 ■ 5 总 结 

你已经 见识过 绝大多 数通过 自定义 Git 客 户端和 服务端 来来适 应自己 工作流 程和项 目内容 
的方 式了。 无 论你创 造出了 什么样 的工作 流程， Git 都 能用的 顺手。 
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世界 不是完 美的。 大多数 时候， 将 所有接 触到的 项目全 部转向 Git 是不可 能的。 有 时我们 
不 得不为 某个项 目使用 其他的 版本控 制系统 （ VCS, Version Control System ) , 其中比 
较常 见的是 Subversion 。 你将 在本章 的第一 部分学 习使用 git svn , Git 为 Subversion 附 
带的双 向桥接 工具。 

或许现 在你已 经在考 虑将先 前的项 目转向 Git 。 本章的 第二部 分将介 绍如何 将项目 迁移到 
Git: 先 介绍从 Subversion 的 迁移， 然后是 Perforce, 最后介 绍如何 使用自 定义的 脚本进 
行非 标准的 导入。 



8.1 Git 与 Subversion 

当前， 大多 数开发 中的开 源项目 以及大 量的商 业项目 都使用 Subversion 来管理 源码。 作 
为最 流行的 开源版 本控制 系统， Subversion 已 经存在 了接近 十年的 时间。 它 在许多 方面与 
CVS 十分 类似， 后 者是前 者出现 之前代 码控制 世界的 霸主。 

Git 最为重 要的特 性之一 是名为 git svn 的 Subversion 双 向桥接 工具。 该 工具把 Git 变 
成了 Subversion 服 务的客 户端， 从 而让你 在本地 享受到 Git 所有的 功能， 而后 直接向 
Subversion 服务 器推送 内容， 仿佛 在本地 使用了 Subversion 客 户端。 也就 是说， 在其他 
人忍受 古董的 同时， 你 可以在 本地享 受分支 合并， 使暂存 区域， 衍合 以及单 项挑拣 等等。 
这 是个让 Git 偷偷潜 入合作 开发环 境的好 东西， 在帮助 你的开 发同伴 们提高 效率的 同时， 它 
还能帮 你劝说 团队让 整个项 目框架 转向对 Git 的 支持。 这个 Subversion 之桥 是通向 分布式 
版本控 制系统 （ DVCS, Distributed VCS ) 世界 的神奇 隧道。 



8.1.1 git svn 

Git 中所有 Subversion 桥接 命令的 基础是 git svn 。 所有 的命令 都从它 开始。 相关 的命令 
数目 不少， 你将通 过几个 简单的 工作流 程了解 到其中 常见的 一些。 

值 得警戒 的是， 在使用 git svn 的 时候， 你实际 是在与 Subversion 交互， Git 比它 要高级 
复杂 的多。 尽管可 以在本 地随意 的进行 分支和 合并， 最 好还是 通过衍 合保持 线性的 提交历 
史， 尽量避 免类似 与远程 Git 仓库动 态交互 这样的 操作。 

避免修 改历史 再重新 推送的 做法， 也不 要同时 推送到 并行的 Git 仓库 来试图 与其他 Git 用 
户 合作。 Subersion 只能 保存单 一的线 性提交 历史， 一不 小心就 会被搞 糊涂。 合作团 队中同 
时 有人用 SVN 和 Git, —定 要确保 所有人 都使用 SVN 服务 来协作 —— 这会 让生活 轻松很 
多。 
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8.1.2 初 始设定 

为 了展示 功能， 先 要一个 具有写 权限的 SVN 仓库。 如 果想尝 试这个 范例， 你必须 复制一 
份其中 的测试 仓库。 比较 简单的 做法是 使用一 个名为 svnsync 的 工具。 较新的 Subversion 
版 本中都 带有该 工具， 它将 数据编 码为用 于网络 传输的 格式。 

要尝试 本例， 先在 本地新 建一个 Subversion 仓库： 



$ mkdir /tmp/test-svn 




$ svnadmin create /tmp/test-svn 




然后， 允许 所有用 户修改 revprop ― 


- 简 单的做 法是添 加一个 总是以 0 作为返 回值的 


pre-revprop-change 脚本： 





$ cat /tmp/test-svn/hooks/pre-revprop-change 

#!/bin/sh 

exit 0; 

$ chmod +x /tmp/test-svn/hooks/pre- revprop - change 



现在可 以调用 svnsvnc init 加目标 仓库， 再加 源仓库 的格式 来把该 项目同 步到本 地了: 



$ svnsync init file:///tmp/test-svn http://progit-example.googlecode.com/svn/ 

这将 建立进 行同步 所需的 属性。 可 以通过 运行以 下命令 来克隆 代码： 



$ svnsync sync file:///tmp/test-svn 

Committed revision 1. 

Copied properties for revision 1. 

Committed revision 2. 

Copied properties for revision 2. 

Committed revision 3. 



别 看这个 操作只 花掉几 分钟， 要 是你想 把源仓 库复制 到另一 个远程 仓库， 而不是 本地仓 

库， 那将 花掉接 近一个 小时， 尽管项 目中只 有不到 100 次的 提交。 Subversion 每次 只复制 
一次 修改， 把它推 送到另 一个仓 库里， 然后周 而复始 ——' 惊人的 低效， 但是我 们别无 选择。 

8.1.3 入门 

有 了可以 写入的 Subversion 仓库 以后， 就可以 尝试一 下 典型的 工作流 程了。 我们从 git 
svn clone 命令 开始， 它会 把整个 Subversion 仓库导 入到一 个 本地的 Git 仓 库中。 提醒一 
下， 这 里导入 的是一 个货真 价实的 Subversion 仓库， 所以 应该把 下面的 file : 〃/tmp/t es t- 
svn 换成你 所用的 Subversion 仓库的 URL: 
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$ git svn clone file:///tmp/test-svn -T trunk - b branches -t tags 

Initialized empty Git repository in /Users/schacon/projects/testsvnsync/svn/.git/ 

r1 = b4e387bc68740b5af56c2a5faf4003ae42bd135c (trunk) 

A m4/acx_pthread.m4 

A m4/stl_hash.m4 

r75 = d1957f3b307922124eec6314e15bcda59e3d9610 (trunk) 
Found possible branch point: file:///tmp/test-svn/trunk => \ 

file:///tmp/test-svn /branches/ my-calc-branch, 75 
Found branch parent: (my-calc-branch) d1957f3b307922124eec6314e15bcda59e3d9610 
Following parent with do— switch 
Successfully followed parent 

r76 = 8624824ecc0badd73f40ea2f01fce51894189b01 (my-calc-branch) 
Checked out HEAD: 

file:///tmp/test-svn/branches/my-calc-branch r76 



这 相当于 针对所 提供的 URL 运 行了两 条命令 —— git svn init 加上 git svn fetch 。 可 能会花 
上一段 时间。 我 们所用 的测试 项目仅 仅包含 75 次提 交并且 它的代 码量不 算大， 所以 只有几 
分钟 而已。 不过， Git 仍然需 要提取 每一个 版本， 每次 一个， 再逐个 提交。 对 于一个 包含成 
百 上千次 提交的 项目， 花掉 的时间 则可能 是几小 时甚至 数天。 

- T trunk -b branches -t tags 告诉 Git 该 Subversion 仓库 遵循了 基本的 分支禾 卩标签 命名法 
则。 如果你 的主干 (译注 ： trunk, 相 当于非 分布式 版本控 制里的 master 分支， 代表 开发的 
主线 ）， 分支或 者标签 以不同 的方式 命名， 则应做 出相应 改变。 由 于该法 则的常 见性， 可以 
使用 -s 来代 替整条 命令， 它意 味着标 准布局 （ s 是 Standard layout 的 首字母 ） ， 也就是 
前面 选项的 内容。 下面的 命令有 相同的 效果： 



$ git svn clone file:///tmp/test-svn - s 



现在， 你有 了一个 有效的 Git 仓库， 包含着 导入的 分支和 标签: 



$ git branch -a 

* master 
my-calc-branch 
tags/2.0.2 
tags/ release- 2.0.1 
tags/ release- 2.0.2 
tags/ release-2.0.2rc1 
trunk 



值 得注意 的是， 该工 具分配 命名空 间时和 远程引 用的方 式不尽 相同。 克隆 普通的 Git 仓库 
时， 可以以 origin/tbmnch] 的形式 获取远 程服务 器上所 有可用 的分支 —— 分配 到远程 服务的 
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名 称下。 然而 git svn 假 定不存 在多个 远程服 务器， 所以 把所有 指向远 程服务 的引用 不加区 
分 的保存 下来。 可以用 Git 探 测命令 show-ref 来查 看所有 引用的 全名。 

$ git show-ref 

1cbd4904d9982f386d87f88fce1c24ad7c0f0471 refs/heads/master 
aee1ecc26318164f355a883f5d99cff0c852d3c4 refs/remotes/my-calc-branch 
03d09b0e2aad427e34a6d50ff147128e76c0e0f5 refs/remotes/tags/2.0.2 
50d02cc0adc9da4319eeba0900430ba219b9c376 refs/remotes/tags/release-2.0.1 
4caaa711a50c77879a91b8b90380060f672745cb refs/remotes/tags/release-2.0.2 
1c4cb508144c513ff1214c3488abe66dcb92916f refs/remotes/tags/release-2.0.2rc1 
1cbd4904d9982f386d87f88fce1c24ad7c0f0471 refs/remotes/trunk 




而 普通的 Git 仓 库应该 是这个 模样: 



$ git show-ref 

83e38c7a0af325a9722f2fdc56b10188806d83a1 refs/heads/master 
3e15e38c198baac84223acfc6224bb8b99ff2281 refs/remotes/gitserver/master 
0a30dd3b0c795b80212ae723640d4e5d48cabdff refs/remotes/origin/master 
25812380387fdd55f916652be4881c6f11600d6f refs/remotes/origin/testing 



这里 有两个 远程服 务器： 一 个名为 gitsen/er ， 具 有一个 master 分支； 另 一个叫 origin, 具 
有 master 禾口 testing 两个 分支。 

注 意本例 中通过 git svn 导入 的远程 引用， （ Subversion 的 ） 标签 是当作 远程分 支添加 
的， 而不是 真正的 Git 标签。 导入的 Subversion 仓库仿 佛是有 一个带 有不同 分支的 tags 
远程服 务器。 

8.1.4 提交 至!) Subversion 

有了可 以开展 工作的 （本地 ） 仓库 以后， 你可以 开始对 该项目 做出贡 献并向 上游仓 库提交 
内 容了， Git 这 时相当 于一个 SVN 客 户端。 假如编 辑了一 个文件 并进行 提交， 那么 这次提 
交仅 存在于 本地的 Git 而非 Subversion 服务 器上。 



$ git commit -am 'Adding git-svn instructions to the README' 
[master 97031e5] Adding git-svn instructions to the README 
1 files changed, 1 insertions( + ), 1 deletions ( — ) 




接 下来， 可以 将作出 的修改 推送到 上游。 值 得注意 的是， Subversion 的使 用流程 也因此 
改变了 —— 你可以 在离线 状态下 进行多 次提交 然后一 次性的 推送到 Subversion 的 服务器 
上。 向 Subversion 月 艮务器 推送的 命令是 git svn dcommit: 
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$ git svn dcommit 

Committing to file:///tmp/test— svn/trunk … 

M README.txt 
Committed r79 

M README.txt 
r79 = 938b1a547c2cc92033b74d32030e86468294a5c8 (trunk) 
No changes between current HEAD and refs/ remotes/trunk 
Resetting to the latest refs/remotes/trunk 



所 有在原 Subversion 数据 基础上 提交的 commit 会 一一 提交到 Subversion, 然后你 
本地 Git 的 commit 将被 重写， 加入一 个特别 标识。 这 一步很 重要， 因为 它意味 着所有 
commit 的 SHA- 1 指都 会发生 变化。 这 也是同 时使用 Git 和 Subversion 两 种服务 作为远 
程服务 不是个 好主意 的原因 之一。 检视以 下最后 一个 commit, 你会 找到新 添加的 git- svn - 
id ( 译注： 即本段 开头所 说的特 别标识 ） ： 

$ git log -1 

commit 938b1a547c2cc92033b74d32030e86468294a5c8 

Author: schacon <schacon@4c93b258-373f-1 1de-be05-5f7a86268029> 

Date: Sat May 2 22:06:44 2009 +0000 

Adding git-svn instructions to the README 

git- svn- id: file:///tmp/test-svn/trunk@79 4c93b258-373f-1 1de-be05-5f7a86268029 



注 意看， 原本以 97031e5 开头的 SHA- 1 校 验值在 提交完 成以后 变成了 938b1a5 。 如 
果 既要向 Git 远 程服务 器推送 内容， 又要 推送到 Subversion 远程服 务器， 则必 须先向 
Subversion 推送 （dcommit) , 因为 该操作 会改变 所提交 的数据 内容。 

8.1.5 拉取最 新进展 

如果要 与其他 开发者 协作， 总有 那么一 天你推 送完毕 之后， 其 他人发 现他们 推送自 己修改 

的时候 （与你 推送的 内容） 产生 冲突。 这些 修改在 你合并 之前将 一直被 拒绝。 在 gitsvn 里 
这 种情况 形似： 

$ git svn dcommit 

Committing to file:///tmp/test— svn/trunk … 

Merge conflict during commit: Your file or directory 'README.txt' is probably \ 
out-of-date: resource out of date; try updating at /Users/schacon/libexec/git-\ 
core/git- svn line 482 

为了 解决该 问题， 可 以运行 git svn rebase , 它 会拉取 服务器 上所有 最新的 改变， 再次基 
础上衍 合你的 修改： 
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$ git svn rebase 

M README.txt 
r80 = ff829ab914e8775c7c025d741beb3d523ee30bc4 (trunk) 
First, rewinding head to replay your work on top of it... 
Applying: first user change 

现在， 你做出 的修改 都发生 在服务 器内容 之后， 所以可 以顺利 的运行 dcommit ： 
$ git svn dcommit 

Committing to f i le:///t m p/ test-sv n/t ru n k … 

M README.txt 
Committed r81 

M README.txt 
r81 = 456cbe6337abe49154db70106d1836bc1332deed (trunk) 
No changes between current HEAD and refs/ remotes/trunk 
Resetting to the latest refs/ remotes/trunk 



需要牢 记的一 点是， Git 要求 我们在 推送之 前先合 并上游 仓库中 最新的 内容， 而 git svn 只 
要求 存在冲 突的时 候才这 样做。 假如 有人向 一个文 件推送 了一些 修改， 这时你 要向另 一个文 
件推 送一些 修改， 那么 dcommit 将正常 工作： 

$ git svn dcommit 

Committing to f i le:///t m p/ test-sv n/t ru n k … 

M configure. ac 
Committed r84 

M autogen.sh 
r83 = 8aa54a74d452f82eee10076ab2584c1fc424853b (trunk) 

M configure. ac 
r84 = Cdbac939211ccb18aa744e581e46563af5d962d0 (trunk) 
W: Cl2f23b80f67aaaa1f6f5aaef48fce3263ac71a92 and refs/remotes/trunk differ, \ 
using rebase: 

:100755 100755 efa5a59965fbbb5b2b0a12890f1b351bb5493c18 \ 

015e4c98c482f0fa71e4d5434338014530b37fa6 M autogen.sh 
First, rewinding head to replay your work on top of it... 
Nothing to do. 

这一 点需要 牢记， 因为它 的结果 是推送 之后项 目处于 一个不 完整存 在与任 何主机 上的状 
态。 如 果做出 的修改 无法兼 容但没 有产生 冲突， 则可能 造成一 些很难 确诊的 难题。 这 和使用 

Git 服 务器是 不同的 —— 在 Git 世 界里， 发布 之前， 你可 以在客 户端系 统里完 整的测 试项目 
的 状态， 而在 SVN 永远都 没法确 保提交 前后项 目的状 态完全 一样。 
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即使 还没打 算进行 提交， 你 也应该 用这个 命令从 Subversion 服 务器拉 取最新 修改。 sit 
svn fetch 能获取 最新的 数据， 不过 git svn rebase 才会 在获取 之后在 本地进 行更新 。 



$ git svn rebase 

M generate—descriptor— proto.sh 
r82 = bd16df9173e424c6f52c337ab6efa7f7643282f1 (trunk) 
First, rewinding head to replay your work on top of it... 
Fast-forwarded master to refs/ remotes/trunk. 



不 时地运 行一下 git svn rebase 可 以确保 你的代 码没有 过时。 不过， 运行该 命令时 需要确 
保工作 目录的 整洁。 如 果在本 地做了 修改， 则必须 在运行 git svn rebase 之前 或暂存 工作， 
或 暂时提 交内容 —— 否则， 该命令 会发现 衍合的 结果包 含着冲 突因而 终止。 

8.1.6 Git 分 支问题 

习惯了 Git 的工 作流程 以后， 你 可能会 创建一 些特性 分支， 完 成相关 的开发 工作， 然后合 
并 他们。 如 果要用 git svn 向 Subversion 推送 内容， 那 么最好 是每次 用衍合 来并入 一个单 
一 分支， 而不 是直接 合并。 使用 衍合的 原因是 Subversion 只有一 个线性 的历史 而不像 Git 
那 样处理 合并， 所以 Git svn 在 把快照 转换为 Subversion 的 commit 时只能 包含第 一个祖 
先。 

假设分 支历史 如下： 创 建一个 experiment 分支， 进 行两次 提交， 然后 合并到 master 。 在 
dcommit 的时 候会得 到如下 输出： 



$ git svn dcommit 

Committing to file:///tmp/test-svn/trunk … 

M CHANGES.txt 
Committed r85 

M CHANGES.txt 
r85 = 4bfebeec434d156c36f2bcd18f4e3d97dc3269a2 (trunk) 
No changes between current HEAD and refs/ remotes/trunk 
Resetting to the latest refs/remotes/trunk 
COPYING.txt: locally modified 
INSTALL.txt: locally modified 

M COPYING.txt 

M INSTALL.txt 
Committed r86 

M INSTALL.txt 

M COPYING.txt 
r86 = 2647f6b86ccfcaad4ec58c520e369ec81f7c283c (trunk) 
No changes between current HEAD and refs/ remotes/trunk 
Resetting to the latest refs/ remotes/trunk 

在 一个包 含了合 并历史 的分支 上使用 dcommit 可 以成功 运行， 不过在 Git 项目 的历史 
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中， 它 没有重 写你在 experiment 分支中 的两个 commit —— 另一 方面， 这些 改变却 出现在 
了 SVN 版本 中同一 个合并 commit 中。 

在别人 克隆该 项目的 时候， 只能 看到这 个合并 commit 包含了 所有发 生过的 修改； 他们 
无法获 知修改 的怍者 和时间 等提交 信息。 

8.1.7 Subversion 分支 

Subversion 的 分支和 Git 中 的不尽 相同； 避免过 多的使 用可能 是最好 方案。 不过， 用 git 
svn 创建 和提交 不同的 Subversion 分支 仍是可 行的。 

创 建新的 SVN 分支 

要在 Subversion 中建立 一个新 分支， 需 要运行 git svn branch [分 支名] ： 

$ git svn branch opera 

Copying file:///tmp/test-svn/trunk at r87 to file:///tmp/test-svn/branches/opera... 
Found possible branch point: file:///tmp/test-svn/trunk => \ 

file:///tmp/test-svn/branches/opera, 87 
Found branch parent: (opera) 1f6bfe471083cbca06ac8d4176f7ad4de0d62e5f 
Following parent with do— switch 
Successfully followed parent 

r89 = 9b6fe0b90c5c9adf9165f700897518dbc54a7cbf (opera) 



这相 当于在 Subversion 中的 svn copy trunk branches/opera 命令， 并会对 Subversion 月艮 

务器进 行相关 操作。 值得 注意的 是它没 有检出 和转换 到那个 分支； 如果现 在进行 提交， 将提 

交 到服务 器上的 trunk, 而非 o Pera 。 

8.1.8 切换当 前分支 

Git 通过搜 寻提交 历史中 Subversion 分支 的头部 来决定 dcommit 的 目的地 —— 而它应 
该只有 一个， 那 就是当 前分支 历史中 最近一 次包含 git- svn -id 的 提交。 

如果需 要同时 在多个 分支上 提交， 可以通 过导入 Subversion 上某 个其他 分支的 commit 
来建 立以该 分支为 dcommit 目的地 的本地 分支。 比 如你想 拥有一 个并行 维护的 opera 分支， 
可 以运行 



$ git branch opera remotes/opera 



然后， 如 果要把 op ^分 支并入 trunk (本 地的 master 分支 ） ， 可 以使用 普通的 git 
mer ge 。 不过最 好提供 一条描 述提交 的信息 （通过 -m) , 否 则这次 合并的 记录是 Merge 
branch opera , 而不 是任何 有用的 东西。 

记住， 虽然 使用了 git merge 来进 行这次 操作， 并且 合并过 程可能 比使用 Subversion 简 
单一些 （ 因为 Git 会自动 找到适 合的合 并基础 ） ， 这并不 是一次 普通的 Git 合并 提交。 最 
终 它将被 推送回 commit 无法包 含多个 祖先的 Subversion 服务 器上； 因而 在推送 之后， 它 
将变成 一个包 含了所 有在其 他分支 上做出 的改变 的单一 commit。 把一 个分支 合并到 另一个 
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分支 以后， 你没 法像在 Git 中那样 轻易的 回到那 个分支 上继续 工作。 提交时 运行的 dcommit 
命令 擦除了 全部有 关哪个 分支被 并入的 信息， 因而 以后的 合并基 础计算 将是不 正确的 —— 
dcommit 让 git merge 的结果 变得类 ^( 以于 git merge - -squash。 不幸 的是， 我们 没有什 么好办 
法 来避免 该情况 —— Subversion 无法储 存这个 信息， 所 以在使 用它作 为服务 器的时 候你将 
永 远为这 个缺陷 所困。 为 了不出 现这种 问题， 在把本 地分支 （本 例中的 opem) 并入 trunk 
以后 应该立 即将其 删除。 

8.1.9 对应 Subversion 的命令 

git svn 工具集 合了若 干个与 Subversion 类似的 功能， 对 应的命 令可以 简化向 Git 的转化 
过程。 下面这 些命令 能实现 Subversion 的这些 功能。 

SVN 风格 的历史 

习惯了 Subversion 的人可 能想以 SVN 的风 格显示 历史， 运行 git svn log 可以让 提交历 
史 显示为 SVN 格式： 

$ git svn log 



r87 I schacon I 2009-05-02 16:07:37 -0700 (Sat, 02 May 2009) I 2 lines 
autogen change 



r86 I schacon I 2009-05-02 16:00:21 -0700 (Sat, 02 May 2009) I 2 lines 
Merge branch 'experiment' 



r85 I schacon I 2009-05-02 16:00:09 -0700 (Sat, 02 May 2009) I 2 lines 
updated the changelog 



关于 git svn log , 有两 点需要 注意。 首先， 它可 以离线 工作， 不像 svn log 命令， 需要 
向 Subversion 服务 器索取 数据。 其次， 它 仅仅显 示已经 提交到 Subversion 服务 器上的 
commit。 在本 地尚未 dcommit 的 Git 数 据不会 出现在 这里； 其 他人向 Subversion 服务 
器 新提交 的数据 也不会 显示。 等于 说是显 示了最 近已知 Subversion 服务 器上的 状态。 

SVN 臼志 

类似 git svn log 对 git log 的 模拟， svn annotate 的等效 命令是 git svn blame [文件 名]。 其输 
出 如下： 



$ git svn blame README.txt 
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2 temporal Protocol Buffers 一 Google's data interchange format 

2 temporal Copyright 2008 Google Inc. 

2 temporal http://code.google.com/apis/protocolbuffers/ 

2 temporal 

22 temporal C++ Installation 一 Unix 

22 temporal ======================= 

2 temporal 

79 schacon Committing in git-svn. 
78 schacon 

2 temporal To build and install the C++ Protocol Buffer runtime and the Protocol 

2 temporal Buffer compiler (protoc) execute the following: 

2 temporal 

同样， 它 不显示 本地的 Git 提 交以及 Subversion 上后来 更新的 内容。 

SVN 服务 器信息 

还可 以使用 git svn info 来获取 与运行 svn info 类似的 信息： 

$ git svn info 
Path: . 

URL: https://schacon-test.googlecode.com/svn/trunk 

Repository Root: https://schacon-test.googlecode.com/svn 

Repository UUID: 4c93b258-373f-1 1de-be05-5f7a86268029 

Revision: 87 

Node Kind: directory 

Schedule: normal 

Last Changed Author: schacon 

Last Changed Rev: 87 

Last Changed Date: 2009-05-02 16:07:37 -0700 (Sat, 02 May 2009) 




它与 blame 和 log 的相同 点在于 离线运 行以及 只更新 到最后 一次与 Subversion 服 务器通 
信的 状态。 



略 Subversion 之所略 

假 如克隆 了一个 包含了 Svn: ign 0re 属性的 Subversion 仓库， 就有必 要建立 对应的 
■gitignore 文件 来防止 意外提 交一些 不应该 提交的 文件。 git svn 有两 个有益 于改善 该问题 
的 命令。 第 一个是 git svn create- ignore, 它自 动建立 对应的 .gitignore 文件， 以便下 次提交 
的时候 可以包 含它。 

第二个 命令是 git svn show-ignore, 它把需 要放进 .gitignore 文件中 的内容 打印到 标准输 
出， 方便 我们把 输出重 定向到 项目的 黑名单 文件： 
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$ git svn show-ignore > .git/info/exclude 



这样 一来， 避免了 .gitignore 对 项目的 干扰。 如果你 是一个 Subversion 团队里 唯一的 Git 
用户， 而其他 队友不 喜欢项 目包含 .gitignore, 该方 法是你 的不二 之选。 

8.1.10 Git-Svn 忌、 结 

git svn 工具 集在当 前不得 不使用 Subversion 服 务器或 者开发 环境要 求使用 Subversion 
服务 器的时 候格外 有用。 不妨 把它看 成一个 跛脚的 Git, 然而， 你还是 有可能 在转换 过程中 
碰 到一些 困惑你 和合作 者们的 迷题。 为 了避免 麻烦， 试着遵 守如下 守则： 

□ 保持一 个不 包含由 git merge 生成的 commit 的线 性提交 历史。 将在主 线分支 外进行 

的开 发通通 衍合回 主线； 避 免直接 合并。 
□ 不要 单独建 立和使 用一个 Git 服 务来搞 合作。 可 以为了 加速新 开发者 的克隆 进程建 

立 一个， 但 是不要 向它提 供任何 不包含 git-svn-id 条目的 内容。 甚至 可以添 加一个 

pre-receive 挂钩来 在每一 个提 交信息 中查找 git-svn-id 并拒绝 提交那 些不包 含它的 

commit。 

如果遵 循这些 守则， 在 Subversion 上工作 还可以 接受。 然而， 如果能 迁徙到 真正的 Git 
服 务器， 则能为 团队带 来更多 好处。 



8.2 迁移到 Git 

如果 在其他 版本控 制系统 中保存 了某项 目的代 码而后 决定转 而使用 Git, 那 么该项 目必须 
经 历某种 形式的 迁移。 本节 将介绍 Git 中包含 的一些 针对常 见系统 的导入 脚本， 并将 展示编 
写 自定义 的导入 脚本的 方法。 

8.2.1 导入 

你 将学习 到如何 从专业 重量级 的版本 控制系 统中导 入数据 —— Subversion 和 Perforce 
—— 因 为据我 所知这 二者的 用户是 （向 Git ) 转换 的主要 群体， 而且 Git 为此 二者附 带了高 
质量 的转换 工具。 

8.2.2 Subversion 

读 过前一 节有关 git svn 的内容 以后， 你应 该能轻 而易举 的根据 其中的 指导来 git svn clone 
—个仓 库了； 然后， 停止 Subversion 的 使用， 向一 个新 Git server 推送， 并 开始使 用它。 
想保 留历史 记录， 所花的 时间应 该不过 就是从 Subversion 服 务器拉 取数据 的时间 （可 能要 
等上 好一会 就是了 ） 。 

然而， 这 样的导 入并不 完美； 而且 还要花 那么多 时间， 不如 干脆一 次把它 做对！ 首 当其冲 
的任务 是作者 信息。 在 Subversion, 每个提 交者在 都在主 机上有 一个用 户名， 记录 在提交 
信 息中。 上 节例子 中多处 显示了 schacon , 比如 blame 的输 出以及 git svn log。 如果 想让这 
条信息 更好的 映射到 Git 作者数 据里， 则需要 从 Subversion 用 户名到 Git 作者的 一个映 
射 关系。 建立一 个叫做 user.txt 的 文件， 用如下 格式表 示映射 关系： 
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schacon = Scott Chacon <schacon@geemail.com> 
seise = Someo Nelse <selse@geemail.com> 



通过该 命令可 以获得 SVN 作者的 列表: 



$ svn log ― xml I grep -P " A <author" I sort -u I \ 

perl -pe 's/<author>(.*?)<\/author>/$1 = /' > users.txt 



它 将输出 XML 格式 的日志 —— 你可 以找到 作者， 建立 一个 单独的 列表， 然后从 XML 中 
抽取出 需要的 信息。 （显而 易见， 本方 法要求 主机上 安装了 grep, sort 和 perl. ) 然后 把输出 
重 定向到 user.txt 文件， 然后 就可以 在每一 项的后 面添加 相应的 Git 用户 数据。 

为 git svn 提供 该文件 可以然 它更精 确的映 射作者 数据。 你还 可以在 done 或者 init 后面添 
加 一no- metadata 来阻止 git svn 包 含那些 Subversion 的附加 信息。 这样 import 命令 就变成 
7： 



$ git- svn clone http://my-project.googlecode.com/svn/ \ 
― authors-file=users.txt ― no-metadata - s my— project 



现在 my_ P mject 目录下 导入的 Subversion 应 该比原 来整洁 多了。 原来的 commit 看上去 
是 这样： 

commit 37efa680e8473b615de980fa935944215428a35a 

Author: schacon <schacon@4c93b258-373f-1 1de-be05-5f7a86268029> 

Date: Sun May 3 00:12:22 2009 +0000 

fixed install - go to trunk 

git- svn- id: https://my-project.googlecode.eom/svn/trunk@94 4c93b258-373f-1 Ide- 



be05-5f7a86268029 




现在是 这样： 

commit 03a8785f44c8ea5cdb0e8834b7c8e6c469be2ff2 
Author: Scott Chacon <schacon@geemail.com> 
Date: Sun May 3 00:12:22 2009 +0000 

fixed install - go to trunk 
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不仅作 者一项 干净了 不少， git-svn-id 也 就此消 失了。 

你还需 要一点 post-import (导 入后） 清理 工作。 最起 码的， 应该清 理一下 git svn 创 建的那 
些怪异 的索引 结构。 首先 要移动 标签， 把 它们从 奇怪的 远程分 支变成 实际的 标签， 然 后把剩 
下 的分支 移动到 本地。 

要把标 签变成 合适的 Git 标签， 运行 

$ cp -Rf .git/refs/remotes/tags/* .git/refs/tags/ 
$ rm -Rf .git/refs/remotes/tags 



该 命令将 原本以 tag/ 开头的 远程分 支的索 引变成 真正的 （ 轻巧的 ） 标签。 

接 下来， 把 refs/remotes 下面 剩下的 索引变 成本地 分支： 

$ cp -Rf .git/refs/remotes/* .git/refs/heads/ 
$ rm -Rf .git/ refs/ remotes 



现在 所有的 旧分支 都变成 真正的 Git 分支， 所有的 旧标签 也变成 真正的 Git 标签。 最后一 

项工作 就是把 新建的 Git 服务器 添加为 远程服 务器并 且向它 推送。 下面 是新增 远程服 务器的 
例子： 



$ git remote add origin git@my-git-server:my repository. git 



为 了 让所有 的分支 和标签 都得到 上传， 我们使 用这条 命令: 



$ git push origin ― all 



所 有的分 支和标 签现在 都应该 整齐干 净的躺 在新的 Git 服务器 里了。 
8.2.3 Perforce 

你 将了解 到的下 一个被 导入的 系统是 Perforce. Git 发 行的时 候同时 也附带 了一个 
Perforce 导入 脚本， 不 过它是 包含在 源码的 contrib 部分 —— 而不像 git svn 那 样默认 可用。 
运行它 之前必 须获取 Git 的 源码， 可以在 git.kemel.org 下载： 

$ git clone git://git.kernel.org/pub/scm/g it/git. git 
$ cd git/contrib/fast- import 



在这个 fast-import 目 录下， 应 该有一 个叫做 git- p4 的 Python 可执行 脚本。 主机上 必须装 
有 Python 和 P 4 工具该 导入才 能正常 进行。 例如， 你要从 Perforce 公共代 码仓库 （ 译注： 
Perforce Public Depot, Perforce 官方 提供的 代码寄 存服务 ） 导入 jam 工程。 为了 设定客 
户端， 我 们要把 P4PORT 环 境变量 export 到 Perforce 仓库： 
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$ export P4PORT=public.perforce.com:1666 



运行 git- P 4 clone 命 令将从 Perforce 服务 器导入 jam 项目， 我们需 要给出 仓库和 项目的 
路径以 及导入 的目标 路径： 

$ git-p4 clone //public/jam/src@all /opt/p4import 
Importing from //public/jam/src@all into /opt/p4import 
Reinitialized existing Git repository in /opt/p4import/.git/ 
Import destination: refs/ remotes/p4/master 
Importing revision 4409 (100%) 




现在去 /opt/ P 4im PO rt 目录运 行一下 git log ， 就 能看到 导入的 成果: 



$ git log -2 

commit 1fd4ec126171790efd2db83548b85b1bbbc07dc2 
Author: Perforce staff <support@perforce.com> 
Date: Thu Aug 19 10:18:45 2004 - 0800 

Drop ?c3' moniker of jam- 2.5. Folded rc2 and rc3 RELNOTES into 
the main part of the document. Built new tar/zip balls. 

Only 16 months later. 

[git-p4: depot-paths = "// p u b I i c/j a m/s r c/": change = 4409] 

commit Ca8870db541a23ed867f38847eda65bf4363371d 
Author: Richard Geiger <rmg@perforce.com〉 
Date: Tue Apr 22 20:51:34 2003 - 0800 

Update derived jamgram.c 

[git-p4: depot-paths = "//p u b I i c/j a m/ s r c/": change = 3108] 



每一个 commit 里都有 一个 git- P 4 标识 符。 这 个标识 符可以 保留， 以防 以后需 要引用 
Perforce 的 修改版 本号。 然而， 如果 想删除 这些标 识符， 现在正 是时候 —— 在开启 新仓库 
之前。 可 以通过 git filter-branch 来批 量删除 这些标 识符： 

$ git filter-branch ― msg- filter 1 
sed - e "/ A \[git-p4:/d" 
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Rewrite 1fd4ec126171790efd2db83548b85b1bbbc07dc2 (123/123) 
Ref 'refs/heads/ master' was rewritten 



现在运 行一下 git log, 你会发 现这些 commit 的 SHA-1 校 验值都 发生了 改变， 而那些 
git- P 4 字 串则从 提交信 息里消 失了： 

$ git log -2 

commit 10a16d60cffca14d454a15c6164378f4082bc5b0 
Author: Perforce staff <support@perforce.com> 
Date: Thu Aug 19 10:18:45 2004 - 0800 

Drop 'rc3' moniker of jam- 2.5. Folded rc2 and rc3 RELNOTES into 
the main part of the document. Built new tar/zip balls. 

Only 16 months later. 

commit 2b6c6db31 1dd76c34c66ec1c40a49405e6b527b2 
Author: Richard Geiger <rmg@perforce.com〉 
Date: Tue Apr 22 20:51:34 2003 一 0800 

Update derived jamgram.c 



至此导 入已经 完成， 可 以开始 向新的 Git 服 务器推 送了。 

8.2.4 自定导 入脚本 

如果先 前的系 统不是 Subversion 或 Perforce 之一， 先上网 找一下 有没有 与之对 应的导 
入脚本 —— 导入 CVS, Clear Case, Visual Source Safe, 甚 至存档 目录的 导入脚 本已经 
存在。 假如 这些工 具都不 适用， 或者 使用的 工具很 少见， 抑或你 需要导 入过程 具有更 多可制 
定性， 则应 该使用 git fa S t-im PO rt。 该命令 从标准 输入读 取简单 的指令 来写入 具体的 Git 数 
据。 这 样创建 Git 对象比 运行纯 Git 命令 或者手 动写对 象要简 单的多 （ 更多相 关内容 见第九 
章 ） 。 通 过它， 你可以 编写一 个导入 脚本来 从导入 源读取 必要的 信息， 同时在 标准输 出直接 
输 出相关 指示。 你 可以运 行该脚 本并把 它的输 出管道 连接到 git fa S t-im PO rt。 

下面 演示一 下如何 编写一 个简单 的导入 脚本。 假设 你在进 行一项 工作， 并 且按时 通过把 
工作 目录复 制为以 时间戳 back_YY_MM_DD 命名 的目录 来进行 备份， 现 在你需 要把它 们导入 
Git 。 目 录结构 如下： 

$ Is /opt/import— 什 om 
back— 2009— 01— 02 
back— 2009— 01— 04 
back— 2009— 01— 14 
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back— 2009— 02— 03 
current 

为 了导入 到一个 Git 目录， 我们首 先回顾 一下 Git 储存 数据的 方式。 你 可能还 记得， Git 
本质上 是一个 commit 对象的 链表， 每一 个对象 指向一 个 内容的 快照。 而这 里需要 做的工 
作就 是告诉 fast-import 内容 快照的 位置， 什 么样的 commit 数 据指向 它们， 以及它 们的顺 
序。 我 们采取 一次处 理一个 快照的 策略， 为 每一个 内容目 录建立 对应的 commit , 每一个 
commit 与之前 的建立 链接。 

正如在 第七章 "Git 执 行策略 一例" 一节中 一样， 我们 将使用 Ruby 来编 写这个 脚本， 
因为 它是我 日常使 用的语 言而且 阅读起 来简单 一些。 你可 以用任 何其他 熟悉的 语言来 重写这 
个例子 —— 它仅 需要把 必要的 信息打 印到标 准输出 而已。 同时， 如果你 在使用 Windows, 
这意 味着你 要特别 留意不 要在换 行的时 候引入 回车符 （译注 ： carriage returns, Windows 
换行时 加入的 符号， 通 常说的 V ) —— Git 的 fast-import 对 仅使用 换行符 （ LF ) 而非 
Windows 的 回车符 （ CRLF ) 要 求非常 严格。 

首先， 进 入目标 目录并 且找到 所有子 目录， 每 一个子 目录将 作为一 个快照 被导入 为一个 
commit。 我们将 依次进 入每一 个子目 录并打 印所需 的命令 来导出 它们。 脚本 的主循 环大致 
是 这样： 



last_mark = nil 



# 循环 遍历所 有目录 
Dir.chdir(ARGV[0]) do 
Dir.glob("*").each do Idir 
next if File.file?(dir) 



# 进入目 标目录 
Dir.chdir(dir) do 

last— mark = print_export(dir, last— mark) 
end 
end 
end 



我们 在每一 个目录 里运行 pH n t_ exp0 rt , 它会 取出上 一个快 照的索 引和标 记并返 回本次 
快照的 索引和 标记； 由此我 们就可 以正确 的把二 者连接 起来。 "标记 （mark)" 是 fast- 
import 中对 commit 标 识符的 叫法； 在创建 commit 的 同时， 我们逐 一赋予 一个标 记以便 
以 后在把 它连接 到其他 commit 时 使用。 因此， 在 pr i nt _ export 方法中 要做的 第一件 事就是 
根据目 录名生 成一个 标记： 



mark = convert— dir— to— mark(dir) 



实 现该函 数的方 法是建 立一个 目录的 数组序 列并使 用数组 的索引 值作为 标记， 因为 标记必 
须 是一个 整数。 这个 方法大 致是这 样的： 

218 



Scott Chacon Pro Git 



8.2 节 迁移到 Git 



$marks = □ 

def convert— dir— to— mark(dir) 
if !$marks.include?(dir) 

$marks « dir 
end 

($marks.index(dir) + 1 ).to_s 
end 



有了整 数来代 表每个 commit, 我们 现在需 要提交 附加信 息中的 日期。 由于 日期是 用目录 
名表 示的， 我 们就从 中解析 出来。 print—export 文件的 下一行 将是： 

date = convert_dir_to-date(dir) 



而 convert_dir_to_date 贝 lj 定义为 

def convert_dir_to-date(dir) 
if dir == 'current' 

return Time.now( ).to_i 
else 

dir = dir.gsubt'back-', ") 
(year, month, day) = dtr.split('_') 
return Time. local (year, month, day).to_i 
end 
end 

它为 每个目 录返回 一个整 型值。 提交附 加信息 里最后 一项所 需的是 提交者 数据， 我 们在一 
个全局 变量中 直接定 义之： 

$author = 'Scott Chacon <schacon@example.com>' 



我 们差不 多可以 开始为 导入脚 本输出 提交数 据了。 第一项 信息指 明我们 定义的 是一个 

commit 对象 以及它 所在的 分支， 随后 是我们 生成的 标记， 提交者 信息以 及提交 备注， 然后 
是 前一个 commit 的 索引， 如果有 的话。 代 码大致 这样： 

# 打印导 入所需 的信息 

puts 'commit refs/heads/ master' 

puts 'mark + mark 

puts "committer #{$author} #{date} - 0700" 
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export-data ('imported from ' + dir) 
puts 'from 、！ + last_marl< if last_mark 




时区 （-0700) 处于简 化目的 使用硬 编码。 如果是 从其他 版本控 制系统 导入， 则必 须以变 
量的形 式指明 时区。 提交 备注必 须以特 定格式 给出： 



data (size)\n (contents) 




该格 式包含 了单词 data, 所读取 数据的 大小， 一个换 行符， 最后 是数据 本身。 由 于随后 
指明文 件内容 的时候 要用到 相同的 格式， 我 们写一 个辅助 方法， export—data: 



def export— data(string) 

print "data #{string.size}\n#{string} 
end 



唯一 剩下的 就是每 一个快 照的内 容了。 这简单 的很， 因为它 们分别 处于一 个目录 —— 你可 

以输出 deleeall 命令， 随后 是目录 中每个 文件的 内容。 Git 会正确 的记录 每一个 快照： 

puts 'deleteall' 

Dir.glob("*V*").each do Ifilel next if ！ File.file?(file) 

inline-data (file) 
end 



注意： 由于很 多系统 把每次 修订看 作一个 commit 到另一 个 commit 的变 化量， fast- 
import 也可 以依据 每次提 交获取 一个命 令来指 出哪些 文件被 添加， 删除 或者修 改过， 以及 
修改的 内容。 我 们将需 要计算 快照之 间的差 别并且 仅仅给 出这项 数据， 不过该 做法要 复杂很 
多 —— 还如不 直接把 所有数 据丢给 Git 然它 自己搞 清楚。 假如前 面这个 方法更 适用于 你的数 
据， 参考 fast-import 的 man 帮 助页面 来了解 如何以 这种方 式提供 数据。 

列 举新文 件内容 或者指 明带有 新内容 的已修 改文件 的格式 如下： 



M 644 inline path/to/file 
data (size) 
(file contents) 




这里， 644 是权 限模式 （加 入有 可执行 文件， 则 需要探 测之并 设定为 755 ) , 而 inline 说 
明我 们在本 行结束 之后立 即列出 文件的 内容。 我们的 inline-data 方法大 致是： 
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def inline-data (file, code = 'M', mode = '644') 

content = File. read (file) 

puts "#{code} #{mode} inline #{file}" 

export-data (content) 
end 



我们 重用了 前面定 义过的 expotdata, 因 为这里 和指明 提交注 释的格 式如出 一辙。 
最后一 项工作 是返回 当前的 标记以 便下次 循环的 使用。 



return mark 



注意： 如果 你在用 Windows, —定记 得添加 一项 额外的 步骤。 前面 提过， Windows 
使用 CRLF 作 为换行 字符而 Git fast-import 只接受 LF。 为了 绕开这 个问题 来满足 git 
fast-import, 你 需要让 ruby 用 LF 取代 CRLF: 



$stdout.binmode 




搞 定了。 现在 运行该 脚本， 你将得 到如下 内容: 



$ ruby import.rb /opt/import— from 
commit refs/heads/master 
mark :1 

committer Scott Chacon <schacon@geemail.com> 1230883200 -0700 
data 29 

imported from back— 2009— 01 —02deleteall 
M 644 inline file.rb 
data 12 
version two 

commit refs/heads/master 
mark :2 

committer Scott Chacon <schacon@geemail.com> 1231056000 -0700 
data 29 

imported from back— 2009— 01 —04from :1 
deleteall 

M 644 inline file.rb 

data 14 

version three 

M 644 inline new.rb 

data 16 

new version one 
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(...) 

要运 行导入 脚本， 在需要 导入的 目录把 该内容 用管道 定向到 gitfa S t-im PO rt。 你可以 建立一 



个空 目录然 后运行 git init 作为 开头， 然后 运行该 脚本： 


$ git init 




Initialized empty Git repository in /opt/import— to/.git/ 


$ ruby import.rb /opt/import— from I git fast-import 


git-fast-import statistics: 




Alloc'd objects: 5000 




Total objects: 18 ( 


1 duplicates ) 


blobs : 7 ( 


1 duplicates 0 deltas) 


trees : 6 ( 


0 duplicates 1 deltas) 


commits: 5 ( 


0 duplicates 0 deltas) 


tags : 0 ( 


0 duplicates 0 deltas) 


Total branches: 1 ( 


1 loads ) 


marks: 1024 ( 


5 unique ) 


atoms: 3 




Memory total: 2255 KiB 


pools: 2098 KiB 




objects: 156 KiB 




pack-report: getpagesizet ) 


= 4096 


pack-report: core.packedGitWindowSize = 33554432 


pack-report: core.packedGitLimit = 268435456 


pack-report: pack— used— ctr 


= 9 


pack-report: pack-mmap-calls = 5 


pack— report: pack— operuwii 


idows = 1 / 1 


pack-report: pack-mapped 


= 1356 / 1356 





你会 发现， 在它 成功执 行完毕 以后， 会 给出一 堆有关 已完成 工怍的 数据。 上 例在一 个分支 

导入了 5 次提交 数据， 包含了 18 个 对象。 现在可 以运行 git log 来检 视新的 历史： 



$ git log -2 

commit 10bfe7d22ce15ee25b60a824c8982157ca593d41 
Author: Scott Chacon <schacon@example.com> 
Date: Sun May 3 12:57:39 2009 -0700 

imported from current 
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commit 7e519590de754d079dd73b44d695a42c9d2df452 
Author: Scott Chacon <schacon@example.com> 
Date: Tue Feb 3 01:00:00 2009 -0700 

imported from back— 2009— 02-03 



就它了 个干净 整洁的 Git 仓库。 需要 注意的 是此时 没有任 何内容 被检出 —— 刚开始 

当前目 录里没 有任何 文件。 要获取 它们， 你 得转到 master 分支的 所在： 

$ Is 

$ git reset ― hard master 

HEAD is now at 10bfe7d imported from current 
$ Is 

file.rb lib 



fast-import 还可以 做更多 —— 处 理不同 的文件 模式， 二进制 文件， 多重 分支与 合并， 标 
签， 进 展标识 等等。 一些更 加复杂 的实例 可以在 Git 源码的 comib/fast-import 目录里 找到； 
其 中较为 出众的 是前面 提过的 git- P 4 脚本。 

8.3 总结 

现 在的你 应该掌 握了在 Subversion 上使用 Git 以及把 几乎任 何先存 仓库无 损失的 导入为 
Git 仓库。 下一章 将介绍 Git 内 部的原 始数据 格式， 从而 是使你 能亲手 锻造其 中的每 一个字 
节， 如 果必要 的活。 
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Git 内 部原理 



不管你 是从前 面的章 节直接 跳到了 本章， 还是 读完了 其余各 章一直 到这， 你 都将在 本章见 

识 Git 的 内部工 作原理 和实现 方式。 我个人 发现学 习这些 内容对 于理解 Git 的用处 和强大 
是 非常重 要的， 不过也 有人认 为这些 内容对 于初学 者来说 可能难 以理解 且过于 复杂。 正因如 
此我把 这部分 内容放 在最后 一章， 你 在学习 过程中 可以先 阅读这 部分， 也可以 晚点阅 读这部 
分， 这 完全取 决于你 自己。 

既然已 经读到 这了， 就让 我们开 始吧。 首先要 弄明白 一点， 从根本 上来讲 Git 是一 套内容 
寻址 （content- addressable) 文件 系统， 在此之 上提供 了一个 VCS 用户 界面。 马上 你就会 
学到这 意味着 什么。 

早期的 Git (主 要是 1.5 之前 版本） 的用 户界面 要比现 在复杂 得多， 这是因 为它更 侧重于 
成为文 件系统 而不是 一套更 精致的 VCS 。 最 近几年 改进了 UI 从而使 它跟其 他任何 系统一 
样清晰 易用。 即便 如此， 还 是经常 会有一 些陈腔 滥调提 到早期 Git 的 UI 复杂又 难学。 

内 容寻址 文件系 统层相 当酷， 在 本章中 我会先 讲解这 部分。 随 后你会 学到传 输机制 和最终 
要使用 的各种 库管理 任务。 



9.1 底 层命令 （Plumbing) 和高 层命令 （Porcelain) 

本 书讲解 了使用 checkout, branch, remote 等共约 30 个 Git 命令。 然 而由于 Git —开 始被 
设 计成供 VCS 使用 的工具 集而不 是一整 套用户 友好的 VCS, 它还包 含了许 多底层 命令， 
这 些命令 用于以 UNIX 风格 使用或 由脚本 调用。 这些命 令一般 被称为 "plumbing" 命令 
(底 层命令 ）， 其 他的更 友好的 命令则 被称为 "porcelain" 命令 （高 层命令 ） 。 

本 书前八 章主要 专门讨 论高层 命令。 本章 将主要 讨论底 层命令 以理解 Git 的内部 工作机 
制、 演示 Git 如何 及为何 要以这 种方式 工作。 这些 命令主 要不是 用来从 命令行 手工使 用的， 
更多的 是用来 为其他 工具和 自 定 义脚本 服务的 。 

当 你在一 个新目 录或已 有目录 内执行 git init 时， Git 会创建 一个 .git 目录， 几 乎所有 Git 
存 储和操 作的内 容都位 于该目 录下。 如 果你要 备份或 复制一 个库， 基本 上将这 一目录 拷贝至 
其他地 方就可 以了。 本 章基本 上都讨 论该目 录下的 内容。 该目 录结构 如下： 



$ Is 
HEAD 

branches/ 
config 
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description 

hooks/ 

index 

info/ 

objects/ 

refs/ 



该目 录下有 可能还 有其他 文件， 但这 是一个 全新的 git init 生成 的库， 所以默 认情况 下这些 
就 是你能 看到的 结构。 新 版本的 Git 不 再使用 branches 目录， description 文 件仅供 GitWeb 
程序 使用， 所以 不用关 心这些 内容。 ccmfig 文件包 含了项 目特有 的配置 选项， info 目录保 
存了一 份不 希望在 .gitignore 文 件中管 理的忽 略模式 （ignored patterns) 的 全局可 执行文 
件。 hooks 目录 保存了 第七章 详细介 绍了的 客户端 或服务 端钩子 脚本。 

另外还 有四个 重要的 文件或 目录： HEAD 及 index 文件， objects 及 refs 目录。 这些是 Git 
的核心 部分。 objects 目录 存储所 有数据 内容， refs 目录 存储指 向数据 （分支 ） 的提交 对象的 
指针， HEAD 文件指 向当前 分支， index 文件保 存了暂 存区域 信息。 马上 你将详 细了解 Git 
是如 何操纵 这些内 容的。 

9.2 Git 对象 

Git 是一套 内容寻 址文件 系统。 很 不错。 不 过这是 什么意 思呢？ 这种说 法的意 思是， Git 
从核 心上来 看不过 是简单 地存储 键值对 （ key-value ) 。 它 允许插 入任意 类型的 内容， 并会 
返 回一个 键值， 通 过该键 值可以 在任何 时候再 取出该 内容。 可以 通过底 层命令 hash-object 
来示范 这点， 传 一些数 据给该 命令， 它会 将数据 保存在 .git 目 录并返 回表示 这些数 据的键 
值。 首 先初使 化一个 Git 仓库 并确认 objects 目录是 空的： 

$ mkdir test 
$ cd test 
$ git init 

Initialized empty Git repository in /tmp/test/.git/ 

$ find .git/objects 

.git/objects 

.git/objects/info 

.git/objects/pack 

$ find .git/objects -type f 

$ 



Git 初 始化了 objects 目录， 同 时在该 目录下 创建了 pack 和 info 子 目录， 但 是该目 录下没 
有其 他常规 文件。 我们 往这个 Git 数据 库里存 储一些 文本： 

$ echo 'test content' I git hash-object - w ― stdin 
d670460b4b4aece5915caf5c68d12f560a9fe3e4 
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参数 -w 指示 hash-object 命 令存储 （数据 ） 对象， 若 不指定 这个参 数该命 令仅仅 返回键 
值。 一stdin 指定从 标准输 入设备 （Stdin) 来读取 内容， 若 不指定 这个参 数则需 指定一 个要存 
储的 文件的 路径。 该命 令输出 长度为 40 个字 符的校 验和。 这是个 SHA-1 哈希值 —— 其值 
为要存 储的数 据加上 你马上 会了解 到的一 种头信 息的校 验和。 现 在可以 查看到 Git 已 经存储 
了 数据： 

$ find .git/objects -type f 

.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4 



可以在 objects 目 录下看 到一个 文件。 这便是 Git 存储数 据内容 的方式 —— 为每份 内容生 
成一个 文件， 取 得该内 容与头 信息的 SHA-1 校 验和， 创 建以该 校验和 前两个 字符为 名称的 
子 目录， 并以 （校 验和） 剩下 38 个字 符为文 件命名 （保 存至子 目录下 )。 

通过 cat-file 命令可 以将数 据内容 取回。 该命令 是查看 Git 对象 的瑞士 军刀。 传入 -p 参数 
可 以让该 命令输 出数据 内容的 类型： 

$ git cat-file - p d670460b4b4aece5915caf5c68d12f560a9fe3e4 
test content 

可以往 Git 中添加 更多内 容并取 回了。 也 可以直 接添加 文件。 比方说 可以对 一个文 件进行 
简单 的版本 控制。 首先， 创建 一个新 文件， 并把 文件内 容存储 到数据 库中： 

$ echo 'version V > test.txt 

$ git hash-object - w test.txt 

83baae61804e65cc73a7201a7252750c76066a30 



接着 往该文 件中写 入一些 新内容 并再次 保存: 

$ echo 'version 2' > test.txt 

$ git hash-object - w test.txt 

1f7a7a472abf3dd9643fd615f6da379c4acb3e3a 



数据 库中已 经将文 件的两 个新版 本连同 一开始 的内容 保存下 来了: 

$ find .git/objects -type f 



.git/objects/1f/7a7a472abf3dd9643fd615f6da379c4acb3e3a 

.git/objects/83/baae61804e65cc73a7201a7252750c76066a30 

.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4 




再 将文件 恢复到 第一个 版本: 
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$ git cat-file - p 83baae61804e65cc73a7201a7252750c76066a30 > test.txt 
$ cat test.txt 
version 1 



或 恢复到 第二个 版本： 

$ git cat-file - p 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a > test.txt 
$ cat test.txt 
version 2 



需 要记住 的是几 个版本 的文件 SHA-1 值可 能与实 际的值 不同， 其次， 存储 的并不 是文件 
名 而仅仅 是文件 内容。 这种 对象类 型称为 blob 。 通 过传递 SHA-1 值给 cat-file -t 命 令可以 
让 Git 返 回任何 对象的 类型： 

$ git cat-file — t 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a 
blob 



9.2.1 tree (树） 对象 

接下 去来看 tree 对象， tree 对 象可以 存储文 件名， 同时也 允许存 储一组 文件。 Git 以一 
种类似 UNIX 文件 系统但 更简单 的方式 来存储 内容。 所有 内容以 tree 或 blob 对象 存储， 
其中 tree 对象 对应于 UNIX 中的 目录， blob 对象 则大致 对应于 inodes 或文件 内容。 一个 
单独的 tree 对象包 含一条 或多条 tree 记录， 每一 条记录 含有一 个指向 blob 或子 tree 对 
象的 SHA-1 指针， 并附 有该对 象的权 限模式 （mode)、 类型和 文件名 信息。 以 simplegit 
项目 为例， 最新的 tree 可能 是这个 样子： 



$ git cat-file - p master A {tree} 




100644 blob a906cb2a4a904a152e80877d4088654daad0c859 


README 


100644 blob 8f94139338f9404f26296befa88755fc2598c289 


Rakefile 


040000 tree 99f1a6d12cb4b6f19c8655fca46c3ecf317074e0 


lib 



masterQftree} 表示 branch 分 支上最 新提交 指向的 tree 对象。 请注意 lib 子 目录并 非一个 
blob 对象， 而是一 个指向 别一个 tree 对象的 指针： 



$ git cat-file - p 99f 1 a6d 1 2cb4b6f 1 9c8655fca46c3ecf 3 1 7074e0 

100644 blob 47c6340d6459e05787f644c2447d2595f5d3a54b simplegitrb 




从 概念上 来讲， Git 保 存的数 据如图 9-1 所示。 
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README Rakefile lib 




tree 



simplegit.rb 



blob 



图 9.1: Git 对象 模型的 简化版 



你 可以自 己创建 tree 。 通常 Git 根据你 的暂存 区域或 index 来创建 并写入 一个 tree 。 
因 此要创 建一个 tree 对 象的活 首先要 通过将 一些文 件暂存 从而创 建一个 index 。 可以使 
用 plumbing 命令 update-index 为 一个单 独文件 —— test.txt 文件 的第一 个版本 —— 创 
建一个 index 。 通过该 命令人 为的将 test.txt 文 件的首 个版本 加入到 了一个 新的暂 存区域 
中。 由于该 文件原 先并不 在暂存 区域中 （甚 至就 连暂存 区域也 还没被 创建出 来呢） ， 必须传 
入 --add 参数; 由于要 添加的 文件并 不在当 前目录 下而是 在数据 库中， 必 须传入 - -cacheinfo 
参数。 同 时指定 了文件 模式， SHA-1 值和文 件名： 



$ git update-index -- add -- cacheinfo 100644 \ 
83baae61804e65cc73a7201a7252750c76066a30 test.txt 



在本 例中， 指定 了文件 模式为 100644, 表明 这是一 个普通 文件。 其他可 用的模 式有： 100755 
表示 可执行 文件， 120000 表 示符号 链接。 文件模 式是从 常规的 UNIX 文 件模式 中参考 来的， 
但是 没有那 么灵活 —— 上述 三种模 式仅对 Git 中 的文件 （blobs) 有效 （虽然 也有其 他模式 
用于 目录和 子模块 ）。 

现在 可以用 vvHte-tree 命令将 暂存区 域的内 容写到 一个 tree 对 象了。 无需 - w 参数 —— 
如 果目标 tree 不 存在， 调用 write- tree 会自 动根据 index 状态创 建一个 tree 对象。 



$ git write- tree 

d8329fc1cc938780ffdd9f94e0d364e0ea74f579 

$ git cat-file -p d8329fdcc938780ffdd9f94e0d364e0ea74f579 

100644 blob 83baae61804e65cc73a7201a7252750c76066a30 test.txt 



可以这 样验证 这确实 是一个 tree 对象: 



$ git cat-file - 1 d8329fc1cc938780ffdd9f94e0d364e0ea74f579 
tree 



再根据 test.txt 的第二 个版本 以及一 个新文 件创建 一个新 tree 对象: 
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$ echo 'new file' > new.txt 
$ git update-index test.txt 
$ git update-index -- add new.txt 



这 时暂存 区域中 包含了 test.txt 的 新版本 及一个 新文件 new.txt 。 创建 （写） 该 tree 对象 
(将 暂存 区域或 index 状 态写入 到一个 tree 对象 )， 然后瞧 瞧它的 样子： 

$ git write- tree 

0155eb4229851634a0f03eb265b69f5a2d56f341 
$ git cat-file - p 0155eb4229851634a0f03eb265b69f5a2d56f341 
100644 blob fa49b077972391ad58037050f2a75f74e3671e92 new.txt 
100644 blob 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a test.txt 



请 注意该 tree 对象包 含了两 个文件 记录， 且 test.txt 的 SHA 值是早 先值的 "第 二版" 
(If7a7a)。 来 点更有 趣的， 你将把 第一个 tree 对象作 为一个 子目录 加进该 tree 中。 可以用 
read-tree 命令将 tree 对象 读到暂 存区域 中去。 在 这时， 通过传 一个 一prefix 参数给 read- 
tree, 将一个 已有的 tree 对 象作为 一个子 tree 读到 暂存区 域中： 

$ git read-tree — prefix=bak d8329fc1cc938780ffdd9f94e0d364e0ea74f579 
$ git write— tree 

3c4e9cd789d88d8d89c1073707c3585e41b0e614 
$ git cat-file - p 3c4e9cd789d88d8d89c1073707c3585e41b0e614 
040000 tree d8329fc1cc938780ffdd9f94e0d364e0ea74f579 bak 
100644 blob fa49b077972391ad58037050f2a75f74e3671e92 new.txt 
100644 blob 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a test.txt 



如果 从刚写 入的新 tree 对象 创建一 个工作 目录， 将得 到位于 工作目 录顶级 的两个 文件和 
—个 名为 bak 的子 目录， 该 子目录 包含了 test.txt 文件的 第一个 版本。 可以将 Git 用 来包含 
这些内 容的数 据想象 成如图 9-2 所示的 样子。 

9.2.2 commit (提交 ） 对象 

你现在 有三个 tree 对象， 它们指 向了你 要跟踪 的项目 的不同 快照， 可是先 前的问 题依然 
存在： 必须记 往三个 SHA-1 值以获 得这些 快照。 你也 没有关 于谁、 何 时以及 为何保 存了这 
些 快照的 信息。 commit 对象 为你保 存了这 些基本 信息。 

要创建 一个 commit 对象， 使用 commit-tree 命令， 指定一 个 tree 的 SHA-1, 如 果有任 
何前 继提交 对象， 也可以 指定。 从 你写的 第一个 tree 开始： 

$ echo 'first commit' I git commit— tree d8329f 
fdf4fc3344e67ab068f836878b6c4951e3b15f3d 
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d8329f 

tree 



test.txt 

83baae 

"version 1 " 

图 9.2: 当前 Git 数 据的内 容结构 
通过 cat-file 查看 这个新 commit 对象： 

$ git cat-file -p fdf4fc3 

tree d8329fc1cc938780ffdd9f94e0d364e0ea74f579 

author Scott Chacon <schacon@gmail.com> 1243040974 - 0700 

committer Scott Chacon <schacon@gmail.com> 1243040974 - 0700 

first commit 

commit 对象有 格式很 简单： 指明了 该时间 点项目 快照的 顶层树 对象、 作者 / 提交 者信息 
( 从 Git 设置的 user.name 和 user.email 中 获得） 以及 当前时 间戳、 一个 空行， 以及提 交注释 

仏 息 o 

接着再 写入另 外两个 commit 对象， 每一个 都指定 其之前 的那个 commit 对象： 

$ echo 'second commit' I git commit- tree 0155eb - p fdf4fc3 

Cac0cab538b970a37ea1e769cbbde608743bc96d 

$ echo 'third commit/ I git commit- tree 3c4e9c - p cacOcab 

1a410efbd13591db07496601ebc7a059dd55cfe9 

每一个 commit 对 象都指 向了你 创建的 树对象 快照。 出 乎意料 的是， 现在 已经有 了真实 
的 Git 历 史了， 所以如 果运行 git log 命令并 指定最 后那个 commit 对象的 SHA-1 便可以 
查看 历史： 

$ git log —stat 1a410e 

commit 1a410efbd13591db07496601ebc7a059dd55cfe9 
Author: Scott Chacon <schacon@gmail.com〉 
Date: Fri May 22 18:15:24 2009 - 0700 



|3c4€9c 
tree 



y ~ i ~ 

new.txt test.txt 



bak 



Ifa49W 
"new file" 



[ If 7a7a 

"version , 
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third commit 
bak/test.txt I 1 + 

1 files changed, 1 insertions( + ), 0 deletions ( — ) 

commit Cac0cab538b970a37ea1e769cbbde608743bc96d 
Author: Scott Chacon <schacon@gmail.com> 
Date: Fri May 22 18:14:29 2009 -0700 

second commit 

new.txt I 1 + 
test.txt I 2 +- 

2 files changed, 2 insertions( + ), 1 deletions ( — ) 

commit fdf4fc3344e67ab068f836878b6c4951e3b15f3d 
Author: Scott Chacon <schacon@gmail.com> 
Date: Fri May 22 18:09:34 2009 -0700 

first commit 

test.txt I 1 + 

1 files changed, 1 insertions( + ), 0 deletions ( — ) 

真棒。 你 刚刚通 过使用 低级操 作而不 是那些 普通命 令创建 了一个 Git 历史。 这基本 上就是 
运行 git add 和 git commit 命令时 Git 进行 的工作 —— 保存修 改了的 文件的 blob, 更新 
索弓 I, 创建 tree 对象， 最 后创建 commit 对象， 这些 commit 对 象指向 了顶层 tree 对象 
以及 先前的 commit 对象。 这三类 Git 对象 —— blob, tree 以及 tree —— 都各自 以文件 
的方式 保存在 .git/objects 目 录下。 以下所 列是目 前为止 样例中 的所有 对象， 每个对 象后面 
的注释 里标明 了 它们 保存的 内 容： 

$ find .git/objects -type f 

.git/objects/01/55eb4229851634a0f03eb265b69f5a2d56f341 # tree 2 
.git/objects/1a/410efbd13591db07496601ebc7a059dd55cfe9 # commit 3 
.git/objects/1f/7a7a472abf3dd9643fd615f6da379c4acb3e3a # test.txt v2 
.git/objects/3c/4e9cd789d88d8d89c1073707c3585e41b0e614 # tree 3 
.git/objects/83/baae61804e65cc73a7201a7252750c76066a30 # test.txt v1 
.git/objects/ca/c0cab538b970a37ea1e769cbbde608743bc96d # commit 2 
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4 # 'test content' 
.git/objects/d8/329fc1cc938780ffdd9f94e0d364e0ea74f579 # tree 1 
.git/objects/fa/49b077972391ad58037050f2a75f74e3671e92 # new.txt 
.git/objects/fd/f4fc3344e67ab068f836878b6c4951e3b15f3d # commit 1 
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如果你 按照以 上描述 进行了 操作， 可以得 到如图 9-3 所 示的对 象图。 

-bak 



Io4i0e 
third commit 





3c4e9c 




tree 



cocdca 

second commit 



Idl5Seb 1 1 

tree 
卜' 



lf7o7o 

"version 2" 



fo49b0 

"new file" 



fdf4fc 
first commit 





d8329f 




tree 



Siboat 
"version ' 



图 9.3: Git 目录 下的所 有对象 



9.2.3 对 象存储 

之前 我提到 当存储 数据内 容时， 同时会 有一个 文件头 被存储 起来。 我们花 些时间 来看看 
Git 是如何 存储对 象的。 你将 看来如 何通过 Ruby 脚本 语言存 储一个 blob 对象 （这 里以字 
符串 "what is up, doc?" 为例） 。 使用 irb 命 令进入 Ruby 交互式 模式： 



$ irb 

» content = "what is up, doc?" 
=> "what is up, doc?" 



Git 以对象 类型为 起始内 容构造 一个文 件头， 本例中 是一个 blob。 然后添 加一个 空格， 接 
着 是数据 内容的 长度， 最后是 一个 空字节 （null byte): 



» header = "blob #{content.length}\0' 
=> "blob 16\000" 



Git 将 文件头 与原始 数据内 容拼接 起来， 并计 算拼接 后的新 内容的 SHA-1 校 验和。 可以 
在 Ruby 中使用 require 语 句导入 SHA1 digest 库， 然 后调用 Digest::SHA1.hexdigest( ) 方法 
计算字 符串的 SHA-1 值： 



» store = header + content 
=> "blob 16\000what is up, doc?" 
» require 'digest/shaV 
=> true 

» shal = Digest::SHA1.hexdigest( store) 

=> M bd9dbf5aae1a3862dd1526723246b20206e5fc37" 
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Git 用 zlib 对 数据内 容进行 压缩， 在 Ruby 中 可以用 zlib 库来 实现。 首先需 要导入 该库, 
然后用 Zlib^Deflate.deflateO 对数 据进行 压縮： 

» require 'zlib' 
=> true 

» zlib— content = Zlib:: Deflate. deflate (store) 

=> l, x\234K\312\311OR04c(\317H,Q\310,V(-\320QH\311O\266\a\000-\034\a\235" 



最 后将用 zlib 压缩 后的内 容写入 磁盘。 需要 指定保 存对象 的路径 （SHA-1 值的 头两个 
字 符作为 子目录 名称， 剩余 38 个字符 怍为文 件名保 存至该 子目录 中）。 在 Ruby 中， 如果 
子目录 不存在 可以用 FileUtil S .mkdir_ P () 函数创 建它。 接着用 File.open 方 法打开 文件， 并用 
writeO 方 法将之 前压缩 的内容 写入该 文件： 



» path = '.git/objects/' + sha1[0,2] + ' /' + s ha1[2,38] 




=> l, .git/objects/bd/9dbf5aae1a3862dd1526723246b20206e5fc37" 




» require 'fileutils' 




=> true 




» FileUti Is. mkdir_p( File. dirname( path ) ) 




=> ".git/objects/bd" 




» File.open(path, 'w') { If I f.write zlib— content } 




=> 32 





这 就行了 —— 你已 经创建 了一个 正确的 blob 对象。 所有的 Git 对象都 以这种 方式存 
储， 惟一 的区 别是类 型不同 —— 除了 字符串 blob, 文件 头起始 内容还 可以是 commit 或 
tree 。 不 过虽然 blob 几 乎可以 是任意 内容， commit 和 tree 的数据 却是有 固定格 式的。 



9.3 Git References 

你可以 执行像 git log 1a410e 这样 的命令 来查看 完整的 历史， 但是这 样你就 要记得 1a410e 
是你最 后一次 提交， 这样 才能在 提交历 史中找 到这些 对象。 你需 要一个 文件来 用一个 简单的 
名 字来记 录这些 SHA-1 值， 这样 你就可 以用这 些指针 而不是 原来的 SHA-1 值去检 索了。 

在 Git 中， 我们 称之为 "引 用" （ references 或者 refs, 译者注 ） 。 你 可以在 .gitAefs 目 
录下面 找到这 些包含 SHA-1 值的 文件。 在 这个项 目里， 这个 目录还 没不包 含任何 文件， 但 
是 包含这 样一个 简单的 结构： 

$ find .gitAefs 

.git/refs 

.git/refs/heads 

.git/refs/tags 

$ find .git/refs -type f 

$ 
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如果想 要创建 一个新 的引用 帮助你 记住最 后一次 提交， 技 术上你 可以这 样做: 



$ echo "1a410efbd13591db07496601ebc7a059dd55cfe9" > .git/refs/heads/master 




现在， 你就 可以在 Git 命 令中使 用你刚 才创建 的引用 而不是 SHA- 1 值: 



$ git log ― pretty=oneline master 

1a410efbd13591db07496601ebc7a059dd55cfe9 third commit 
Cac0cab538b970a37ea1e769cbbde608743bc96d second commit 
fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit 



当然， 我们并 不鼓励 你直接 修改这 些引用 文件。 如果 你确实 需要更 新一个 引用， Git 提供 
了一 个安全 的命令 update- ref: 



$ git update-ref refs/heads/master 1a410efbd13591db07496601ebc7a059dd55cfe9 



基本上 Git 中 的一个 分支其 实就是 一个指 向某个 工怍版 本一条 HEAD 记 录的指 针或引 
用。 你可 以用这 条命令 创建一 个指向 第二次 提交的 分支： 



$ git update-ref refs/heads/test cacOca 




这样 你的分 支将会 只包含 那次提 交以及 之前的 工作: 



$ git log ― pretty=oneline test 

Cac0cab538b970a37ea1e769cbbde608743bc96d second commit 
fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit 



现在， 你的 Git 数 据库应 该看起 来像图 9-4 一样。 

每当 你执行 git branch (分支 名称） 这样的 命令， Git 基 本上就 是执行 update- ref 命令， 把你 
现在 所在分 支中最 后一次 提交的 SHA-1 值， 添加 到你要 创建的 分支的 引用。 

9.3.1 HEAD 标记 

现 在的问 题是， 当 你执行 git branch (分支 名称） 这条 命令的 时候， Git 怎么知 道最后 一次提 
交的 SHA-1 值呢？ 答 案就是 HEAD 文件。 HEAD 文件是 一个 指向你 当前所 在分支 的引用 
标 识符。 这样 的引用 标识符 —— 它看 起来并 不像一 个普通 的引用 —— 其实并 不包含 SHA-1 
值， 而 是一个 指向另 外一个 引用的 指针。 如果 你看一 下这个 文件， 通常 你将会 看到这 样的内 
容： 
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refs/heads/mastef 







third commit 










second commit 






fdf4ft 




first commit 



•Tsm \ test 



： 



"version 2" 



f«49M 

"new We" 



"version 1 



图 9.4: 包 含分支 引用的 Git 目 录对象 



$ cat .git/HEAD 

ref: refs/heads/ master 



如果 你执行 git checkout test, Git 就会更 新这个 文件， 看 起来像 这样: 



$ cat .git/HEAD 
ref: refs/heads/test 



当你 再执行 git commit 命令， 它就创 建了一 个 commit 对象， 把这个 commit 对 象的父 
级 设置为 HEAD 指向的 引用的 SHA-1 值。 

你 也可以 手动编 辑这个 文件， 但 是同样 有一个 更安全 的方法 可以这 样做： S ymb 0 li C - re f。 你 
可以 用下面 这条命 令读取 HEAD 的值： 



$ git symbolic- ref HEAD 
refs/heads/ master 



你也可 以设置 HEAD 的值: 



$ git symbolic- ref HEAD refs/heads/test 
$ cat .git/HEAD 
ref: refs/heads/test 



但是 你不能 设置成 refs 以外的 形式: 



$ git symbolic- ref HEAD test 

fatal: Refusing to point HEAD outside of refs/ 



236 



Scott Chacon Pro Git 



9. 3 节 Git References 



9.3.2 Tags 

你刚刚 已经重 温过了 Git 的 三个主 要对象 类型， 现在 这是第 四种。 Tag 对 象非常 像一个 
commit 对象 —— 包含 一个 标签， 一组 数据， 一个 消息和 一个 指针。 最主 要的区 别就是 Tag 
对象指 向一个 commit 而不是 一个 tree。 它就 像是一 个分支 引用， 但是不 会变化 —— 永远 
指向 同一个 commit, 仅仅是 提供一 个更加 友好的 名字。 

正 如我们 在第二 章所讨 论的， Tag 有两种 类型： annotated 和 lightweight 。 你可 以类似 
下面这 样的命 令建立 一个 lightweight tag: 



$ git update-ref refs/tags/v1.0 Cac0cab538b970a37ea1e769cbbde608743bc96d 



这就是 lightweight tag 的全部 个 永远不 会发生 变化的 分支。 annotated tag 要 

更复杂 一点。 如果 你创建 一个 annotated tag, Git 会创建 一个 tag 对象， 然后 写入一 个指 
向指 向它而 不是直 接指向 commit 的 reference。 你可以 这样创 建一个 annotated tag (-a 
参数表 明这是 一个 annotated tag ) ： 



$ git tag -a v1.1 1a410efbd13591db07496601ebc7a059dd55cfe9 - m 'test tag' 



这是 所创建 对象的 SHA-1 值： 

$ cat .git/refs/tags/v1.1 

95851 91f37f7b0fb9444f35a9bf50de191beadc2 

现 在你可 以运行 cat-file 命令检 查这个 SHA- 1 值： 

$ It cat-file - p 9585191f37f7b0fb9444f35a9bf50de191beadc2 
object 1a410efbd13591db07496601ebc7a059dd55cfe9 
type commit 
tag v1.1 

tagger Scott Chacon <schacon@gmail.com> Sat May 23 16:48:58 2009 一 0700 



test tag 




值得 注意的 是这个 对象指 向你所 标记的 commit 对象的 SHA-1 值。 同时需 要注意 的是它 
并 不是必 须要指 向一个 commit 对象； 你 可以标 记任何 Git 对象。 例如， 在 Git 的 源代码 
里， 管理 者添加 了一个 GPG 公钥 （这 是一个 blob 对象） 对它做 了一个 标签。 你就 可以运 
行： 



$ git cat-file blob junio-gpg-pub 
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来查看 Git 源 代码仓 库中的 公钥. Linux kernel 也有 一个不 是指向 commit 对象的 tag 
—— 第一个 tag 是在 导入源 代码的 时候创 建的， 它指 向初始 tree (initial tree, 译者 
注） 。 

9.3.3 Remotes 

你将会 看到的 第四种 reference 是 remote reference (远程 引用， 译 者注） 。 如 果你添 
加 了一个 remote 然后推 送代码 过去， Git 会把你 最后一 次推送 到这个 remote 的每 个分支 
的值都 记录在 refsAemotes 目 录下。 例如， 你可以 添加一 个叫做 origin 的 remote 然 后把你 
的 master 分 支推送 上去： 

$ git remote add origin git@github.com:schacon/sim pi eg it-prog it. git 
$ git push origin master 
Counting objects: 11， done. 
Compressing objects: 100% (5/5)， done. 
Writing objects: 100% (7/7)， 716 bytes, done. 
Total 7 (delta 2)， reused 4 (delta 1) 
To git@github.com:schacon/simp leg it-prog it.g it 
a1 1bef0..ca82a6d master -> master 



然 后查看 refs/remotes/origin/master 这个 文件， 你就 会发现 origin remote 中的 master 分 

支 就是你 最后一 次和服 务器的 通信。 

$ cat .git/refs/remotes/orig in/master 
Ca82a6dff817ec66f44342007202690a93763949 



Remote 应用 和分支 主要区 别在于 他们是 不能被 check out 的。 Git 把他们 当作是 标记这 
些了这 些分支 在服务 器上最 后状态 的一种 书签。 

9.4 Packfiles 

我 们再来 看一下 test Git 仓库。 目前 为止， 有 11 个对象 —— 4 个 blob, 3 个 tree, 3 
个 commit 以 及一个 tag: 

$ find .git/objects -type f 

.git/objects/01/55eb4229851634a0f03eb265b69f5a2d56f341 # tree 2 
.git/objects/1a/410efbd13591db07496601ebc7a059dd55cfe9 # commit 3 
.git/objects/1f/7a7a472abf3dd9643fd615f6da379c4acb3e3a # tesUxt v2 
.git/objects/3c/4e9cd789d88d8d89c1073707c3585e41b0e614 # tree 3 
.git/objects/83/baae61804e65cc73a7201a7252750c76066a30 # tesUxt v1 
.git/objects/95/85191f37f7b0fb9444f35a9bf50de191beadc2 # tag 
.git/objects/ca/c0cab538b970a37ea1e769cbbde608743bc96d # commit 2 
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.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4 # 'test content' 
.git/objects/d8/329fc1cc938780ffdd9f94e0d364e0ea74f579 # tree 1 
.git/objects/fa/49b077972391ad58037050f2a75f74e3671e92 # new.txt 
.git/objects/fd/f4fc3344e67ab068f836878b6c4951e3b15f3d # commit 1 



Git 用 zlib 压 縮文件 内容， 因 此这些 文件并 没有占 用太多 空间， 所有 文件加 起来总 共仅用 
了 925 字节。 接下去 你会添 加一些 大文件 以演示 Git 的一 个很有 意思的 功能。 将你 之前用 
到过的 Grit 库中的 repo.rb 文件 加进去 —— 这个 源代码 文件大 小约为 12K: 

$ curl http://github.com/mojombo/grit/raw/master/lib/grit/repo.rb > repo.rb 



$ git add repo.rb 




$ git commit -m 'added repo.rb' 




[master 484a592] added repo.rb 




3 files changed, 459 insertions( + ), 2 deletions ( — ) 




delete mode 100644 bak/test.txt 




create mode 100644 repo.rb 




rewrite test.txt (100%) 




如果查 看一下 生成的 tree, 可 以看到 repo.rb 文件的 


blob 对象的 SHA-1 值： 


$ git cat-file - p master A {tree} 




100644 blob fa49b077972391ad58037050f2a75f74e3671e92 


new.txt 


100644 blob 9bc1dc421dcd51 b4ac296e3e5b6e2a99cf44391e 


repo.rb 


100644 blob e3f094f522629ae358806b17daf78246c27c007b 


test.txt 



然后 可以用 git cat-file 命令查 看这个 对象有 多大: 



$ git cat-file - s 9bc1dc421dcd51b4ac296e3e5b6e2a99cf 44391 e 
12898 



稍 微修改 一下些 文件， 看会 发生些 什么： 

$ echo '# testing' » repo.rb 
$ git commit -am 'modified repo a bit' 
[master ablafef] modified repo a bit 
1 files changed, 1 insertions( + ), 0 deletions ( — ) 




查 看这个 commit 生成的 tree, 可以看 到一些 有趣的 东西: 
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$ git cat-file - p master A {tree} 

100644 blob fa49b077972391ad58037050f2a75f74e3671e92 new.txt 
100644 blob 05408d195263d853f09dca71d551 16663690c27c repo.rb 

100644 blob e3f094f522629ae358806b17daf78246c27c007b test.txt 



blob 对象与 之前的 已经不 同了。 这 说明虽 然只是 往一个 400 行的文 件最后 加入了 一行内 
容， Git 却 用一个 全新的 对象来 保存新 的文件 内容： 

$ git cat-file — s 05408d195263d853f09dca71d55116663690c27c 
12908 



你 的磁盘 上有了 两个几 乎完全 相同的 12K 的 对象。 如果 Git 只 完整保 存其中 一个， 并保 
存另一 个对象 的差异 内容， 岂不 更好？ 

事实上 Git 可以那 样做。 Git 往磁 盘保存 对象时 默认使 用的格 式叫松 散对象 （loose 
object) 格式。 Git 时不时 地将这 些对象 打包至 一个叫 packfile 的二进 制文件 以节省 空间并 
提高 效率。 当 仓库中 有太多 的松散 对象， 或是手 工调用 git gc 命令， 或推送 至远程 服务器 
时， Git 都会这 样做。 手 工调用 git gc 命令让 Git 将 库中对 象打包 并看会 发生些 什么： 

$ git gc 

Counting objects: 17， done. 
Delta compression using 2 threads. 
Compressing objects: 100% (13/13)， done. 
Writing objects: 100% (17/17), done. 
Total 17 (delta 1), reused 10 (delta 0) 



查 看一下 objects 目录， 会 发现大 部分对 象都不 在了， 与 此同时 出现了 两个新 文件: 



$ find .git/objects -type f 




.git/objects/71/08f7ecb345ee9d0084193f147cdad4d2998293 




.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4 




.git/objects/info/packs 




.git/objects/pack/pack-7a16e4488ae40c7d2bc56ea2bd43e25212a66c45.idx 




.git/objects/pack/pack-7a16e4488ae40c7d2bc56ea2bd43e25212a66c45.pack 





仍保 留着的 几个对 象是未 被任何 commit 引用的 blob —— 在此 例中是 你之前 创建的 
"what is up, doc?" 禾 n "test content" 这两 个示例 blob。 你从 没将他 们添加 至任何 
commit, 所以 Git 认为 它们是 " 悬空" 的， 不会 将它们 打包进 packfile 。 

剩 下的文 件是新 创建的 packfile 以 及一个 索引。 packfile 文 件包含 了刚才 从文件 系统中 
移除 的所有 对象。 索 引文件 包含了 packfile 的偏移 信息， 这样 就可以 快速定 位任意 一个指 
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定 对象。 有 意思的 是运行 gc 命 令前磁 盘上的 对象大 小约为 12K , 而 这个新 生成的 packfile 
仅为 6K 大小。 通过打 包对象 减少了 一半磁 盘使用 空间。 

Git 是如何 做到这 点的？ Git 打包对 象时， 会查 找命名 及尺寸 相近的 文件， 并只保 存文件 
不同版 本之间 的差异 内容。 可以查 看一下 packfile , 观察它 是如何 节省空 间的。 gitverify- 
pack 命 令用于 显示已 打包的 内容： 

$ git verify- pack - v \ 

.git/objects/pack/pack-7a16e4488ae40c7d2bc56ea2bd43e25212a66c45.idx 
0155eb4229851634a0f03eb265b69f5a2d56f341 tree 71 76 5400 
05408d195263d853f09dca71d55116663690c27c blob 12908 3478 874 
09f01cea547666f58d6a8d809583841a7c6f0130 tree 106 107 5086 
1a410efbd13591db07496601ebc7a059dd55cfe9 commit 225 151 322 
1f7a7a472abf3dd9643fd615f6da379c4acb3e3a blob 10 19 5381 
3c4e9cd789d88d8d89c1073707c3585e41b0e614 tree 101 105 5211 
484a59275031909e19aadb7c92262719cfcdf19a commit 226 153 169 
83baae61804e65cc73a7201a7252750c76066a30 blob 10 19 5362 
95851 91f37f7b0fb9444f35a9bf50de191beadc2 tag 136 127 5476 
9bc1dc421dcd51b4ac296e3e5b6e2a99cf44391e blob 7 18 5193 1 \ 

05408d195263d853f09dca71d55116663690c27c 
ab1afef80fac8e34258ff41fc1b867c702daa24b commit 232 157 12 
Cac0cab538b970a37ea1e769cbbde608743bc96d commit 226 154 473 
d8329fc1cc938780ffdd9f94e0d364e0ea74f579 tree 36 46 5316 
e3f094f522629ae358806b17daf78246c27c007b blob 1486 734 4352 
f8f51d7d8a1760462eca26eebafde32087499533 tree 106 107 749 
fa49b077972391ad58037050f2a75f74e3671e92 blob 9 18 856 
fdf4fc3344e67ab068f836878b6c4951e3b15f3d commit 177 122 627 
chain length = 1: 1 object 

Pack-7a16e4488ae40c7d2bc56ea2bd43e25212a66c45.pack: ok 




如果你 还记得 的活， 9bdd 这个 blob 是 repo.rb 文件的 第一个 版本， 这个 blob 引用了 
05408 这个 blob, 即该 文件的 第二个 版本。 命 令输出 内容的 第三列 显示的 是对象 大小， 可以 
看到 05408 占用了 12K 空间， 而 9bc1d 仅为 7 字节。 非 常有趣 的是第 二个版 本才是 完整保 
存文件 内容的 对象， 而第一 个版本 是以差 异方式 保存的 —— 这 是因为 大部分 情况下 需要快 
速访 问文件 的最新 版本。 

最妙的 是可以 随时进 行重新 打包。 Git 自 动定期 对仓库 进行重 新打包 以节省 空间。 当然也 
可以手 工运行 git gc 命 令来这 么做。 

9.5 The Refspec 

这本 书读到 这里， 你已经 使用过 一些简 单的远 程分支 到本地 引用的 映射方 式了， 这 种映射 
可 以更为 复杂。 假 设你像 这样添 加了一 项远程 仓库： 
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$ git remote add origin git@github.com:schacon/simplegit-progit.git 



它 在你的 .git/config 文件中 添加了 一节， 指定 了远程 的名称 （origin), 远程 仓库的 URL 地 
址， 和用 于获取 操作的 Refspec: 

[remote "origin"] 

url = git@github.com:schacon/simplegit-progit.git 
fetch = +refs/heads/*:refs/remotes/origin/* 

Refspec 的格式 是一个 可选的 + 号， 接着是 < src > : <dst> 的 格式， 这里 < src > 是远端 上的引 
用 格式， <dst> 是将 要记录 在本地 的引用 格式。 可选的 + 号告诉 Git 在 即使不 能快速 演进的 
情 况下， 也去 强制更 新它。 

缺省 情况下 refspec 会被 git remote add 命令 所自动 生成， Git 会获取 远端上 refs/heads/ 
下面 的所有 引用， 并将它 写入到 本地的 refs/remotes/origin/. 所以， 如果远 端上有 一个 
master 分支， 你在本 地可以 通过下 面这种 方式来 访问它 的历史 记录： 



$ git log origin/ master 

$ git log remotes/origin/master 

$ git log refs/remotes/origin/master 




它们 全是等 价的， 因为 Git 把 它们都 扩展成 refsAemotes/origin/master. 
如果 你想让 Git 每次 只拉取 远程的 master 分支， 而不 是远程 的所有 分支， 你 可以把 fetch 
这一行 修改成 这样： 



fetch = +refs/heads/master:refs/remotes/orig in/master 



这是 git fetch 操 作对这 个远端 的缺省 refspec 值。 而 如果你 只想做 一次该 操作， 也可以 
在命令 行上指 定这个 refspec. 如 可以这 样拉取 远程的 master 分支到 本地的 origin/mymaster 
分支： 



$ git fetch origin master:refs/ remotes/ origin/ mymaster 



你 也可以 在命令 行上指 定多个 refspec. 像这 样可以 一次获 取远程 的多个 分支: 



$ git fetch origin master:refs/ remotes/ origin/ mymaster \ 
topic:refs/remotes/origin/topic 
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From git@github.com:schacon/simplegit 

！ [rejected] master -> origin/ mymaster ( non fast forward) 



[new branch] topic -〉 origin/topic 




在 这个例 子中， master 分支 因为不 是一个 可以快 速演进 的引用 而拉取 操作被 拒绝。 你可 
以在 refspec 之前使 用一个 + 号来重 载这种 行为。 

你也 可以在 配置文 件中指 定多个 refspec. 如你想 在每次 获取时 都获取 master 和 experiment 
分支， 就添加 两行： 

[remote "origin"] 

url = git@github.com:schacon/simplegit-progit.git 

fetch = +refs/heads/ master:refs/ remotes/origin/ master 

fetch = +refs/heads/experiment:refs/ remotes/origin/experiment 



但是 这里不 能使用 部分通 配符， 像 这样就 是不合 法的: 



fetch = +refs/heads/qa*:refs/remotes/origin/qa 



但无论 如何， 你可 以使用 命名空 间来达 到这个 目的。 如你 有一个 QA 组， 他 们推送 一系列 
分支， 你想每 次获取 master 分支和 QA 组 的所有 分支， 你 可以使 用这样 的配置 段落： 

[remote "origin"] 

url = git@github.com:schacon/simplegit-progit.git 
fetch = +refs/heads/ master:refs/ remotes/origin/ master 
fetch = +refs/heads/qa/*:refs/remotes/origin/qa/* 



如果 你的工 作流很 复杂， 有 QA 组 推送的 分支、 开 发人员 推送的 分支、 和集 成人员 推送的 
分支， 并 且他们 在远程 分支上 协作， 你 可以采 用这种 方式为 他们创 建各自 的命名 空间。 

9.5.1 推送 Refspec 

采用 命名空 间的方 式确实 很棒， 但 QA 组 成员第 1 次 是如何 将他们 的分支 推送到 qa / 空间 
里面 的呢？ 答案 是你可 以使用 refspec 来 推送。 

如果 QA 组成 员想把 他们的 master 分支 推送到 远程的 qa/master 分 支上， 可 以这样 运行： 



$ git push origin master:refs/heads/qa/master 

如果他 们想让 Git 每 次运行 git push origin 时都这 样自动 推送， 他们 可以在 配置文 件中添 
力卩 push 值： 
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[remote "origin"] 

url = git@github.com:schacon/sim pi eg it-prog it. git 
fetch = +refs/heads/*:refs/ remotes/origin/* 
push = refs/heads/master:refs/heads/qa/master 



这样， 就会让 git push origin 缺 省就把 本地的 master 分支 推送到 远程的 qa/master 分支 
上。 

9.5.2 删 除引用 

你也可 以使用 refspec 来删除 远程的 引用， 是通 过运行 这样的 命令： 

$ git push origin :topic 



因为 refspec 的 格式是 < src > : <dst>, 通过把 < src > 部分 留空的 方式， 这个意 思是是 把远程 
的 topic 分支变 成空， 也 就是删 除它。 

9.6 传 输协议 

Git 可以以 两种主 要的方 式跨越 两个仓 库传输 数据： 基于 HTTP 协议 之上， 和 file:〃, ssh:〃, 
和 git:// 等智 能传输 协议。 这 一节带 你快速 浏览这 两种主 要的协 议操作 过程。 

9.6.1 哑协议 

Git 基于 HTTP 之 上传输 通常被 称为哑 协议， 这是因 为它在 服务端 不需要 有针对 Git 特 
有的 代码。 这个获 取过程 仅仅是 一系列 GET 请求， 客户 端可以 假定服 务端的 Git 仓库 中的布 
局。 让 我们以 simplegit 库 来看看 http-fetch 的 过程： 



$ git clone http://github.com/schacon/simplegit-progit.git 



它 做的第 1 件 事情就 是获取 info/refs 文件。 这个文 件是在 服务端 运行了 update-server-info 
所生 成的， 这 也解释 了为什 么在服 务端要 想使用 HTTP 传输， 必须 要开启 post-receive 钩 



=> GET info/ refs 

Ca82a6dff817ec66f44342007202690a93763949 refs/heads/master 




现在 你有一 个远端 引用和 SHA 值的 列表。 下一步 是寻找 HEAD 引用， 这样你 就知道 了在完 
成后， 什 么应该 被检出 到工作 目录： 
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=> GET HEAD 

ref: refs/heads/master 



这 说明在 完成获 取后， 需 要检出 master 分支。 这时， 已经可 以开始 漫游操 作了。 因为你 
的起 点是在 infoAefs 文 件中所 提到的 ca82a6 commit 对象， 你的开 始操怍 就是获 取它： 

=> GET Objects/ca/82a6dff817ec66f44342007202690a93763949 
(179 bytes of binary data) 



然 后你取 回了这 个对象 - 这 在服务 端是一 个松散 格式的 对象， 你使 用的是 静态的 HTTP 
GET 请求获 取的。 可 以使用 zlib 解压 縮它， 去除其 头部， 查 看它的 commmit 内容： 

I git cat-file -p ca82a6dff817ec66f44342007202690a93763949 

tree Cfda3bf379e4f8dba8717dee55aab78aef7f4daf 

parent 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 

author Scott Chacon <schacon@gmail.com> 1205815931 - 0700 

committer Scott Chacon <schacon@gmail.com> 1240030591 -0700 

changed the version number 



这样， 就 得到了 两个需 要进一 步获取 的对象 - cfda3b 是这个 commit 对象所 对应的 tree 
对象， 和 085bb3 是 它的父 对象； 

=> GET Objects/08/5bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 
(179 bytes of data) 



这样就 取得了 这它的 下一步 commit 对象， 再抓取 tree 对象： 

=> GET 0bjects/cf/da3bf379e4f8dba8717dee55aab78aef7f4daf 
(404 - Not Found) 

Oops - 看起 来这个 tree 对象在 服务端 并不以 松散格 式对象 存在， 所以 得到了 404 晌应, 
代表在 HTTP 服务 端没有 找到该 对象。 这 有好几 个原因 - 这个 对象可 能在替 代仓库 里面, 
或 者在打 包文件 里面， Git 会首先 检查任 何列出 的替代 仓库： 

=> GET objects/info/http-alternates 
(empty file) 
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如果这 返回了 几个替 代仓库 列表， 那么 它会去 那些地 方检查 松散格 式对象 和文件 - 这是 
一种 在软件 分叉之 间共享 对象以 节省磁 盘的好 方法。 然而， 在 这个例 子中， 没 有替代 仓库。 
所以 你所需 要的对 象肯定 在某个 打包文 件中。 要 检查服 务端有 哪些打 包格式 文件， 你需要 

获取 objects/info/packs 文件， 这里面 包含有 打包文 件列表 （ 是的， 它 也是被 update-server- 
info 所 生成的 ) ； 

=> GET objects/info/ packs 

P pack-816a9b2334da9953e530f27bcac22082a9f5b835.pack 

这里 服务端 只有一 个打包 文件， 所以 你要的 对象显 然就在 里面。 但是 你可以 先检查 它的索 
引 文件以 确认。 这在服 务端有 多个打 包文件 时也很 有用， 因为这 样就可 以先检 查你所 需要的 
对象 空间是 在哪一 个打包 文件里 面了： 

=> GET Objects/pack/pack-816a9b2334da9953e530f27bcac22082a9f5b835.idx 
(4k of binary data) 

现在你 有了这 个打包 文件的 索引， 你可以 看看你 要的对 象是否 在里面 - 因 为索引 文件列 
出了 这个打 包文件 所包含 的所有 对象的 SHA 值， 和该 对象存 在于打 包文件 中的偏 移量， 所 
以你 只需要 简单地 获取整 个打包 文件： 

=> GET Objects/pack/pack-816a9b2334da9953e530f27bcac22082a9f5b835.pack 
(13k of binary data) 



现在 你也有 了这个 tree 对象， 你可以 继续在 commit 对象上 漫游。 它们全 部都在 这个你 
已 经下载 到的打 包文件 里面， 所 以你不 用继续 向服务 端请求 更多下 载了。 在 这完成 之后， 
由 于下载 开始时 已探明 HEAD 引用 是指向 master 分支， Git 会将 它检出 到工作 目录。 

整个过 程看起 来就像 这样： 

$ git clone http://github.com/schacon/simplegit-progit.git 
Initialized empty Git repository in /private/tmp/simplegit-progit/.git/ 
got ca82a6dff817ec66f44342007202690a93763949 
walk ca82a6dff817ec66f44342007202690a93763949 
got 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 

Getting alternates list for http://github.com/schacon/simplegit-progit.git 
Getting pack list for http://github.com/schacon/simplegit-progit.git 
Getting index for pack 816a9b2334da9953e530f27bcac22082a9f5b835 
Getting pack 816a9b2334da9953e530f27bcac22082a9f5b835 
which contains Cfda3bf379e4f8dba8717dee55aab78aef7f4daf 
walk 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 
walk a1 1 bef06a3f659402fe7563abf99ad00de2209e6 
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9.6.2 智 能协议 

这个 HTTP 方法 是很简 单但效 率不是 很高。 使 用智能 协议是 传送数 据的更 常用的 方法。 这 
些协 议在远 端都有 Git 智能 型进程 在服务 - 它可以 读出本 地数据 并计算 出客户 端所需 要的， 
并生 成合适 的数据 给它， 这有两 类传输 数据的 进程： 一 对用于 上传数 据和一 对用于 下载。 

上 传数据 

为 了上传 数据至 远端， Git 使用 send- pack 禾口 receive- pack 进程。 这个 send- pack 进程运 
行 在客户 端上， 它连接 至远端 运行的 receive-pack 进程。 

举例 来说， 你 在你的 项目上 运行了 git push origin master, 并且 origin 被定 义为一 个使用 
SSH 协议的 URL。 Git 会使用 send-pack 进程， 它会 启动一 个基于 SSH 的连 接到服 务器。 它 
尝 试像这 样透过 SSH 在服务 端运行 命令： 



$ ssh -x git@github.com "git- receive- pack 'schacon/si m p leg it-prog it.g it" 1 
005bca82a6dff817ec66f4437202690a93763949 refs/heads/master report-status delete-refs 
003e085bb3bcb608e1e84b2432f8ecbe6306e7e7 refs/heads/topic 
0000 

这里的 git-receive-pack 命令 会立即 对它所 拥有的 每一个 引用晌 应一行 - 在 这个例 子中， 
只有 master 分支 和它的 SHA 值。 这里第 1 行 也包含 了服务 端的能 力列表 （这 里是 report- 
status 禾口 delete-refs ) 。 

每 一行以 4 字节 的十 六进制 开始， 用 于指定 整行的 长度。 你 看到第 1 行以 005b 开始， 这在 
十 六进制 中表示 91, 意 味着第 1 行有 91 字 节长。 下 一行以 003e 起始， 表示有 62 字 节长， 所以 
需要读 剩下的 62 字节。 再下 一行是 0000 开始， 表 示服务 器已完 成了引 用列表 过程。 

现 在它知 道了服 务端的 状态， 你的 send-pack 进 程会判 断哪些 commit 是它 所拥有 但服务 
端没 有的。 针 对每个 引用， 这次 推送都 会告诉 对端的 receive-pack 这个 信息。 举 例说， 如果 
你 在更新 master 分支， 并 且增加 experiment 分支， 这个 send-pack 将 会是像 这样： 



0085ca82a6dff817ec66f44342007202690a93763949 15027957951b64cf874c3557a0f3547bd83b3ff6 refs/ 
heads/ master report-status 

heads/experiment 
0000 



这里 的全' 0' 的 SHA-1 值表示 之前没 有过这 个对象 - 因为你 是在添 加新的 experiment 
引用。 如果 你在删 除一个 引用， 你会 看到相 反的： 就 是右边 是全' 0' 。 

Git 针对每 个引用 发送这 样一行 信息， 就 是旧的 SHA 值， 新的 SHA 值， 和将 要更新 的引用 
的 名称。 第 1 行 还会包 含有客 户端的 能力。 下 一步， 客户 端会发 送一个 所有那 些服务 端所没 
有的对 象的一 个打包 文件。 最后， 服务端 以成功 (或者 失败) 来 响应： 



OOOAunpack ok 
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下 载数据 

当你在 下载数 据时， fetch-pack 和 upload-pack 进程 就起作 用了。 客户 端启动 fetch-pack 
进程， 连接至 远端的 upload-pack 进程， 以协商 后续数 据传输 过程。 

在 远端仓 库有不 同的方 式启动 upload-pack 进程。 你可以 使用与 receive-pack 相同 的透过 
SSH 管道的 方式， 也可 以通过 Git 后 台来启 动这个 进程， 它默认 监听在 9418 号端 口上。 这 
里 fetch-pack 进程 在连接 后像这 样向后 台发送 数据： 



003fg it-upload-pack schacon/simpleg it-prog it.git\Ohost=myserver.com\0 



它 也是以 4 字 节指定 后续字 节长度 的方式 开始， 然 后是要 运行的 命令， 和 一个空 字节， 然 
后 是服务 端的主 机名， 再跟随 一个最 后的空 字节。 Git 后 台进程 会检查 这个命 令是否 可以运 
行， 以及 那个仓 库是否 存在， 以及 是否具 有公开 权限。 如果 所有检 查都通 过了， 它会 启动这 
个 upload-pack 进程并 将客户 端的请 求移交 给它。 

如果 你透过 SSH 使 用获取 功能， fetch-pack 会 像这样 运行： 



$ ssh -x git@github.com "git- upload - pack 'schacon/simpleg it-prog it.g it" 



不 管哪种 方式， 在 fetch-pack 连接 之后， upload- pack 都 会以这 种形式 返回: 



0088ca82a6dff817ec66f44342007202690a93763949 HEAD\Omulti_ack thin-pack \ 

side-band side— band- 64k ofs— delta shallow no-progress include- tag 
003fca82a6dff817ec66f44342007202690a93763949 refs/heads/master 
003e085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 refs/heads/topic 
0000 



这与 receive- pack 响应很 类似， 但 是这里 指的能 力是不 同的。 而 且它还 会指出 HEAD 引 
用， 让 客户端 可以检 查是否 是一份 克隆。 

在 这里， fetch- pack 进程 检查它 自己所 拥有的 对象和 所有它 需要的 对象， 通 过发送 
"want" 和所需 对象的 SHA 值， 发送 "have" 和所 有它已 拥有的 对象的 SHA 值。 在列表 
完 成时， 再发送 "done" 通知 upload-pack 进 程开始 发送所 需对象 的打包 文件。 这 个过程 
看 起来像 这样： 



0054want ca82a6dff817ec66f44342007202690a93763949 ofs-delta 
0032have 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 
0000 

0009done 



这 是传输 协议的 一个很 基础的 例子， 在更复 杂的例 子中， 客户 端可能 会支持 multLack 或 
者 side-band 能力； 但 是这个 例子中 展示了 智能协 议的基 本交互 过程。 
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9.7 维 护及数 据恢复 

你时不 时的需 要进行 一些清 理工作 —— 如减 小一个 仓库的 大小， 清 理导入 的库， 或是恢 
复 丢失的 数据。 本节将 描述这 类使用 场景。 

9.7.1 维护 

Git 会不 定时地 自动运 行称为 "autogc" 的 命令。 大 部分情 况下该 命令什 么都不 处理。 
不过要 是存在 太多松 散对象 (loose object, 不在 packfile 中的 对象） 或 packfile, Git 会进 
行调用 git gc 命令。 gc 指垃 圾收集 （garbage collect), 此 命令会 做很多 工作： 收集 所有松 
散对象 并将它 们存入 packfile, 合 并这些 packfile 进一 个大的 packfile, 然 后将不 被任何 
commit 引用 并且已 存在一 段时间 （数月 ） 的对象 删除。 

可以手 工运行 auto gc 命令： 



$ git gc ― auto 



再次 强调， 这个命 令一般 什么都 不干。 如果有 7,000 个 左右的 松散对 象或是 50 个 以上的 
packfile, Git 才会真 正调用 gc 命令。 可 能通过 修改配 置中的 gc.auto 和 gc.autopacklimit 来 
调整 这两个 阈值。 

gc 还会 将所 有引用 （references) 并入一 个单独 文件。 假设仓 库中包 含以下 分支和 标签： 

$ find .git/refs -type f 
.git/ refs/heads/experiment 
.git/ refs/heads/ master 
.git/refs/tags/v1.0 
.git/refs/tags/v1.1 

这时如 果运行 git gc, refs 下的 所有文 件都会 消失。 Git 会将 这些文 件挪到 .git/packed-refs 
文 件中去 以提高 效率， 该 文件是 这个样 子的： 

$ cat .git/ packed-refs 
# pack— refs with: peeled 

Cac0cab538b970a37ea1e769cbbde608743bc96d refs/heads/experiment 
ab1afef80fac8e34258ff41fc1b867c702daa24b refs/heads/master 
Cac0cab538b970a37ea1e769cbbde608743bc96d refs/tags/v1.0 
9585191f37f7b0fb9444f35a9bf50de191beadc2 refs/tags/vl.1 
A 1a410efbd13591db07496601ebc7a059dd55cfe9 



当更新 一个引 用时， Git 不会修 改这个 文件， 而是在 refs/heads 下写入 一个新 文件。 当查 
找一个 引用的 SHA 时， Git 首先在 refs 目录下 查找， 如 果未找 到则到 packed- refs 文 件中去 
查找。 因此 如果在 refs 目录 下找不 到一个 引用， 该 引用可 能存到 packed- refs 文件中 去了。 

请留 意文件 最后以 □ 开 头的那 一行。 这 表示该 行上一 行的那 个标签 是一个 annotated 标 
签， 而 该行正 是那个 标签所 指向的 commit 。 
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9.7.2 数 据恢复 

在使用 Git 的过 程中， 有时 会不小 心丢失 commit 信息。 这一般 出现在 以下情 况下： 强 
制删除 了一个 分支而 后又想 重新使 用这个 分支， hard-reset 了一 个分 支从而 丢弃了 分支的 
部分 commit。 如果这 真的发 生了， 有什么 办法把 丢失的 commit 找回 来呢？ 

下面的 示例演 示了对 test 仓 库主分 支进行 hard-reset 到一 个老 版本的 commit 的 操作， 
然 后恢复 丢失的 commit 。 首先 查看一 下当前 的仓库 状态： 

$ git log ― pretty=oneline 

ab1afef80fac8e34258ff41fc1b867c702daa24b modified repo a bit 
484a59275031909e19aadb7c92262719cfcdf19a added repo.rb 
1a410efbd13591db07496601ebc7a059dd55cfe9 third commit 
Cac0cab538b970a37ea1e769cbbde608743bc96d second commit 
fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit 



接着将 master 分 支移回 至中间 的一个 commit: 

$ git reset —hard 1a410efbd13591db07496601ebc7a059dd55cfe9 
HEAD is now at 1a410ef third commit 
$ git log ― pretty=oneline 

1a410efbd13591db07496601ebc7a059dd55cfe9 third commit 
Cac0cab538b970a37ea1e769cbbde608743bc96d second commit 
fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit 



这样 就丢弃 了最新 的两个 commit —— 包含 这两个 commit 的分 支不存 在了。 现 在要做 
的是找 出最新 的那个 commit 的 SHA, 然 后添加 一个指 它它的 分支。 关键在 于找出 最新的 
commit 的 SHA —— 你 不大可 能记住 了这个 SHA, 是吧？ 

通常 最快捷 的办法 是使用 git reflog 工具。 当你 （在 一个仓 库下） 工 怍时， Git 会 在你每 
次 修改了 HEAD 时悄悄 地将改 动记录 下来。 当你 提交或 修改分 支时， reflog 就会 更新。 git 
update-ref 命 令也可 以更新 reflog， 这是 在本章 前面的 "Git References" 部分我 们使用 
该命令 而不是 手工将 SHA 值写入 ref 文件的 理由。 任何时 间运行 git reflog 命 令可以 查看当 
前的 状态： 

$ git reflog 

1a410ef HEAD@{0}: 1a410efbd13591db07496601ebc7a059dd55cfe9: updating HEAD 
ablafef HEAD@{1}: ab1afef80fac8e34258ff41fc1b867c702daa24b: updating HEAD 



可以 看到我 们签出 的两个 commit ， 但没 有更多 的相关 信息。 运行 git log -g 会输出 
reflog 的正常 日志， 从而 显示更 多有用 信息： 
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$ git log -g 

commit 1a410efbd13591db07496601ebc7a059dd55cfe9 

Reflog: HEAD@{0} (Scott Chacon <schacon@gmail.com>) 

Reflog message: updating HEAD 

Author: Scott Chacon <schacon@gmail.com> 

Date: Fri May 22 18:22:37 2009 -0700 

third commit 

commit ab1afef80fac8e34258ff41fc1 b867c702daa24b 

Reflog: HEAD@{1} (Scott Chacon <schacon@gmail.com>) 

Reflog message: updating HEAD 

Author: Scott Chacon <schacon@gmail.com> 

Date: Fri May 22 18:15:24 2009 -0700 

modified repo a bit 



看 起来弄 丢了的 commit 是底下 那个， 这样 在那个 commit 上创建 一个新 分支就 能把它 
恢复 过来。 比 方说， 可以 在那个 commit (ablafef) 上 创建一 个名为 recover-branch 的分 
支： 

$ git branch recover- branch ablafef 

$ git log ― pretty=oneline recover- branch 

ab1afef80fac8e34258ff41fc1b867c702daa24b modified repo a bit 
484a59275031909e19aadb7c92262719cfcdf19a added repo.rb 
1a410efbd13591db07496601ebc7a059dd55cfe9 third commit 
Cac0cab538b970a37ea1e769cbbde608743bc96d second commit 
fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit 



酷 ！ 这样有 了一个 跟原来 master —样的 recover-branch 分支， 最新 的两个 commit 又找 
回 来了。 接着， 假 设引起 commit 丢失 的原因 并没有 记录在 reflog 中 —— 可以通 过删除 
recover-branch 和 reflog 来模 拟这种 情况。 这 样最新 的两个 commit 不会被 任何东 西引用 
到： 

$ git branch -D recover-branch 
$ rm - Rf .git/logs/ 

因为 reflog 数据是 保存在 .git/logs/ 目录 下的， 这样 就没有 reflog 了。 现 在要怎 样恢复 
commit 呢？ 办 法之一 是使用 git fsck 工具， 该工具 会检查 仓库的 数据完 整性。 如果指 定一 
ful 选项， 该命令 显示所 有未被 其他对 象引用 （指向 ） 的所有 对象： 
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$ git fsck —full 

dangling blob Cl670460b4b4aece5915caf5c68d12f560a9fe3e4 
dangling commit ab1afef80fac8e34258ff41fc1b867c702daa24b 
dangling tree aea790b9a58f6cf6f2804eeac9f0abbe9631e4c9 
dangling blob 7108f7ecb345ee9d0084193f 147cdad4d2998293 

本 例中， 可以从 dangling commit 找到丢 失了的 commit。 用相 同的方 法就可 以恢复 
它， 即创 建一个 指向该 SHA 的 分支。 

9.7.3 移 除对象 

Git 有许 多过人 之处， 不 过有一 个功能 有时却 会带来 问题： git done 会将包 含每一 个文件 
的所 有历史 版本的 整个项 目下载 下来。 如 果项目 包含的 仅仅是 源代码 的活这 并没有 什么坏 
处， 毕竟 Git 可以 非常高 效地压 縮此类 数据。 不过 如果有 人在某 个时刻 往项目 中添加 了一个 
非 常大的 文件， 那们 即便他 在后来 的提交 中将此 文件删 掉了， 所 有的签 出都会 下载这 个大文 
件。 因为历 史记录 中引用 了这个 文件， 它会 一直存 在着。 

当你将 Subversion 或 Perforce 仓 库转换 导入至 Git 时这会 成为一 个很 严重的 问题。 在 
此类系 统中， （签 出时） 不会 下载整 个仓库 历史， 所以这 种情形 不大会 有不良 后果。 如果你 
从 其他系 统导入 了一个 仓库， 或是 发觉一 个仓库 的尺寸 远超出 预计， 可 以用下 面的方 法找到 
并 移除大 （尺寸 ） 对象。 

警告： 此方 法会破 坏提交 历史。 为了 移除对 一个大 文件的 引用， 从最早 包含该 引用的 tree 
对象开 始之后 的所有 commit 对象 都会被 重写。 如果在 刚导入 一个仓 库并在 其他人 在此基 
础上开 始工作 之前这 么做， 那 没有什 么问题 —— 否 则你不 得不通 知所有 协作者 （贡 献者) 
去衍 合你新 修改的 commit 。 

为 了演示 这点， 往 test 仓库 中加入 一个大 文件， 然 后在下 次提交 时将它 删除， 接 着找到 
并将这 个文件 从仓库 中永久 删除。 首先， 加一个 大文件 进去： 

$ curl http://kernei.org/pub/software/scm/git/git-1. 6. 3. 1.tar.bz2 > git.tbz2 
$ git add git.tbz2 

$ git commit -am 'added git tarball' 
[master 6df7640] added git tarball 

1 files changed, 0 insertions( + ), 0 deletions (-) 

create mode 100644 git.tbz2 




喔， 你 并不想 往项目 中加进 一个这 么大的 tar 包。 最后 还是去 掉它: 



$ git rm git.tbz2 
rm 'git.tbz2' 

$ git commit -m 'oops - removed large tarball' 
[master da3f30d] oops - removed large tarball 

1 files changed, 0 insertions( + ), 0 deletions ( — ) 

delete mode 100644 git.tbz2 
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对仓 库进行 gc 操作， 并查看 占用了 空间: 

$ git gc 

Counting objects: 21, done. 
Delta compression using 2 threads. 
Compressing objects: 100% (16/16), done. 
Writing objects: 100% (21/21), done. 
Total 21 (delta 3), reused 15 (delta 1) 



可 以运行 count-objects 以查 看使用 了多少 空间: 

$ git count-objects - v 
count: 4 
size: 16 
in-pack: 21 
packs: 1 
size-pack: 2016 
prune-packable: 0 
garbage: 0 



size-pack 是以 千字节 为单位 表示的 packfiles 的 大小， 因 此已经 使用了 2MB 。 而 在这次 
提 交之前 仅用了 2K 左右 —— 显然 在这次 提交时 删除文 件并没 有真正 将其从 历史记 录中删 
除。 每当 有人复 制这个 仓库去 取得这 个小项 目时， 都不 得不复 制所有 2MB 数据， 而 这仅仅 
因为你 曾经不 小心加 了个大 文件。 当我 们来解 决这个 问题。 

首 先要找 出这个 文件。 在本 例中， 你知道 是哪个 文件。 假设 你并不 知道这 一点， 要 如何找 
出哪个 （些） 文件占 用了这 么多的 空间？ 如 果运行 git gc, 所有对 象会存 入一个 packfile 文 
件； 运行另 一个底 层命令 git verify-pack 以识 别出大 对象， 对输 出的第 三列信 息即文 件大小 
进行 排序， 还可以 将输出 定向到 tail 命令， 因为 你只关 心排在 最后的 那几个 最大的 文件： 

$ git verify- pack -v .git/objects/ pack/ pack-3f8c0...bb.idx I sort -k 3 -n I tail - 3 
e3f094f522629ae358806b17daf78246c27c007b blob 1486 734 4667 
05408d195263d853f09dca71d55116663690c27c blob 12908 3478 1189 
7a9eb2fba2b1811321254ac360970fc169ba2330 blob 2056716 2056872 5401 

最 底下那 个就是 那个大 文件： 2MB 。 要查看 这到底 是哪个 文件， 可以 使用第 7 章 中已经 
简单使 用过的 rev-list 命令。 若给 rev-list 命 令传入 一objects 选项， 它会列 出所有 commit 
SHA 值， blob SHA 值 及相应 的文件 路径。 可以这 样查看 blob 的文 件名： 

$ git rev-list ― objects -- all I grep 7a9eb2fb 
7a9eb2fba2b1811321254ac360970fc169ba2330 gittbz2 
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接 下来要 将该文 件从历 史记录 的所有 tree 中 移除。 很 容易找 出哪些 commit 修改 了这个 
文件： 

$ git log ― pretty=oneline -- git.tbz2 

da3f30d019005479c99eb4c340622561 3985a Idb oops - removed large tarball 
6df764092f3e7c8f5f94cbe08ee5cf42e92a0289 added git tarball 



必须 重写从 6df76 开始 的所有 commit 才能将 文件从 Git 历史 中完全 移除。 这么做 需要用 
到第 6 章 中 用过的 filter-branch 命令： 



$ git filter-branch 一一 index-filter \ 

'git rm ― cached ― ignore-unmatch git.tbz2' -- 6df7640 A .. 
Rewrite 6df764092f3e7c8f5f94cbe08ee5cf42e92a0289 (1/2)rm 'gittbz2' 
Rewrite da3f30d019005479c99eb4c3406225613985a1db (2/2) 
Ref 'refs/heads/master' was rewritten 



-index-filter 选项类 似于第 6 章 中 使用的 一tree-filter 选项， 但这里 不是传 入一个 命令去 
修改 磁盘上 签出的 文件， 而是修 改暂存 区域或 索引。 不能用 rm file 命 令来删 除一个 特定文 
件， 而是 必须用 git rm -cached 来 删除它 —— 即 从索引 而不是 磁盘删 除它。 这样做 是出于 
速 度考虑 —— 由于 Git 在运 行你的 filter 之 前无需 将所有 版本签 出到磁 盘上， 这个 操作会 
快 得多。 也 可以用 一tree-filter 来完成 相同的 操作。 git rm 的 一ignore-unmatch 选项 指定当 
你 试图删 除的内 容并不 存在时 不显示 错误。 最后， 因为 你清楚 问题是 从哪个 commit 开始 
的， 使用 filter-branch 重写自 6df7640 这个 commit 开 始的所 有历史 记录。 不 这么做 的活会 
重写所 有历史 记录， 花费 不必要 的更多 时间。 

现 在历史 记录中 已经不 包含对 那个文 件的引 用了。 不过 reflog 以 及运行 filter-branch 时 
Git 往 .gitAefs/original 添加的 一些 refs 中仍有 对它的 引用， 因 此需要 将这些 引用删 除并对 
仓 库进行 repack 操作。 在进行 repack 前需要 将所有 对这些 commits 的引用 去除： 

$ rm -Rf .git/refs/original 
$ rm -Rf .git/logs/ 
$ git gc 

Counting objects: 19, done. 
Delta compression using 2 threads. 
Compressing objects: 100% (14/14), done. 
Writing objects: 100% (19/19), done. 
Total 19 (delta 3), reused 16 (delta 1) 




看一 下节省 了多少 空间。 



$ git count-objects 一 v 
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count: 8 
size: 2040 
in-pack: 19 
packs: 1 
size-pack: 7 
prune-packable: 0 
garbage: 0 



repack 后 仓库的 大小减 小到了 7I〈 , 远小于 之前的 2MB 。 从 size 值可以 看出大 文件对 
象还在 松散对 象中， 其实 并没有 消失， 不过 这没有 关系， 重要 的是在 再进行 推送或 复制， 这 
个对 象不会 再传送 出去。 如果真 的要完 全把这 个对象 删除， 可 以运行 git pmne —expire 命 
令。 

9.8 总结 

现在你 应该对 Git 可以 作什么 相当了 解了， 并且在 一定程 度上也 知道了 Git 是如 何实现 
的。 本 章覆盖 了许多 plumbing 命令 —— 这些命 令比较 底层， 且比你 在本书 其他部 分学到 
的 porcelain 命令 要来得 简单。 从底 层了解 Git 的工 作原理 可以帮 助你更 好地理 解为何 Git 
实现 了目前 的这些 功能， 也使你 能够针 对你的 工作流 写出自 己的 工具和 脚本。 

Git 作为一 套 content-addressable 的文件 系统， 是一 个非常 强大的 工具， 而不仅 仅只是 
一个 VCS 供人 使用。 希 望借助 于你新 学到的 Git 内部 原理的 知识， 你 可以实 现自己 的有趣 
的 应用， 并以更 高级便 利的方 式使用 Git。 
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